Комментарии 9
Статья пустая.
Почему другой порт удобней и безопасней?
Зачем отдельный пхп скрипт — почему сам браузер не заставить webdav юзать?
А надо ли «другие» методы кроме PUT — и если нет, как их закрыть?
А какой вообще use-case у всех телодвижений?
Почему другой порт удобней и безопасней?
Зачем отдельный пхп скрипт — почему сам браузер не заставить webdav юзать?
А надо ли «другие» методы кроме PUT — и если нет, как их закрыть?
А какой вообще use-case у всех телодвижений?
возможно браузера в цепочке и нет, может это сторедж какой-нибудь?
Вы это понимаете, я это понимаю. Но из статьи это не вытекает — статья вообще только про один-единственный ключик для сборки nginx'а и один option для curl'а.
Огромный пласт остаётся вне поля зрения — начиная с secuity этого решения и заканчивая вообще целью — а то может мне это нужно, а я и не знаю? И не узнаю, из такой статьи.
Огромный пласт остаётся вне поля зрения — начиная с secuity этого решения и заканчивая вообще целью — а то может мне это нужно, а я и не знаю? И не узнаю, из такой статьи.
Логично же — про другой порт вряд ли узнает кто то еще кроме тебя самого. А так же используя отдельный порт в скриптах при обращении ты четко идентифицируешь, то с чем работаешь.
В смысле «зачем отдельный скрипт»? Такова задача, изначально чтобы на сервере «клиенте» прежде чем отослать запрос и файл требуется ряд телодвижений. Так же не факт что PHP скрипт инициализируется браузером. Может быть отработка по крону, etc.
Прочтите статью внимательней, в конфигурационном файле указано что
«dav_methods PUT; #разрешенные методы, нам требуется только PUT». Соответственно если нам нужен\не нужен другой метод то мы используем директиву dav_methods.
Я привел пример настройки WebDav на nginx как альтернативу WebDav на apache. Учитывая что информации по подобной конфигурации в сети очень мало, то думаю что разные вариации использования такой схемы — найдут себе применение.
В смысле «зачем отдельный скрипт»? Такова задача, изначально чтобы на сервере «клиенте» прежде чем отослать запрос и файл требуется ряд телодвижений. Так же не факт что PHP скрипт инициализируется браузером. Может быть отработка по крону, etc.
Прочтите статью внимательней, в конфигурационном файле указано что
«dav_methods PUT; #разрешенные методы, нам требуется только PUT». Соответственно если нам нужен\не нужен другой метод то мы используем директиву dav_methods.
Я привел пример настройки WebDav на nginx как альтернативу WebDav на apache. Учитывая что информации по подобной конфигурации в сети очень мало, то думаю что разные вариации использования такой схемы — найдут себе применение.
> Логично же — про другой порт вряд ли узнает кто то еще кроме тебя самого.
Портов всего 65к, и при исследовании любого сервера первое действие — скан портов на тему «а где что висит».
В прямом — задача врядли стояла «сделайте возмонжость передать файл через PUT без использования PHP скрипта на том сервере». Задача решалась всё-таки какая-то другая. Какая? Почему решалась именно через WebDAV, а не FTP, например? Тот же CURL прекрасно загружает файлы и по FTP.
Портов всего 65к, и при исследовании любого сервера первое действие — скан портов на тему «а где что висит».
В прямом — задача врядли стояла «сделайте возмонжость передать файл через PUT без использования PHP скрипта на том сервере». Задача решалась всё-таки какая-то другая. Какая? Почему решалась именно через WebDAV, а не FTP, например? Тот же CURL прекрасно загружает файлы и по FTP.
Можно долго разглагольствовать на тему безопасности, я всего лишь сделал маленький шаг для защиты от дурака. Естественно тот же nmap быстро все вам расскажет.
Антон, вы не поверите, но задача стояла прямо так как вы и произнесли. PUT без PHP обработчика на принимающей стороне. Зачем на принимающем сервере ради передачи файлов поднимать PHP? Nginx прекрасно справляется с задачей тратя значительно меньше ресурсов чем apache.
FTP не для этого создан был. А PUT идеально подходит для этой задачи так как не имеет ограничения по длине запроса в отличии от других методов. (GET, POST)
Антон, вы не поверите, но задача стояла прямо так как вы и произнесли. PUT без PHP обработчика на принимающей стороне. Зачем на принимающем сервере ради передачи файлов поднимать PHP? Nginx прекрасно справляется с задачей тратя значительно меньше ресурсов чем apache.
FTP не для этого создан был. А PUT идеально подходит для этой задачи так как не имеет ограничения по длине запроса в отличии от других методов. (GET, POST)
1. Зачем делать из Debian'а помойку make'ом?
2. http_dav_module даже в 0.6.32 есть, зачем его перекомпиливать?
2. http_dav_module даже в 0.6.32 есть, зачем его перекомпиливать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebDav и Nginx