softwarerА за этим делом откройте RFC и прочитайте, что в случае http с ненулевой вероятностью вообще не удастся определить, передан ли файл до конца или оборван на середине. Пользователи всяких качалок типа ReGet-а хорошо помнят такие проблемы.Качалки, которые не в состоянии определить допустимость многопоточного скачивания, никак не могут быть проблемой протокола.

P.S. Когда меня запарила работа ftp, на который приходилось выгружать дампы базы для анализа разработчиками, я начал выкладывать их на нашем сайте и передавать коротенькое:

softwarerМногопоточность тут не при чём. Проблемой протокола является допустимость молчаливого завершения сеанса как признака успехаТолько в отсутствии заголовка Content-Length.
Но, опять-таки, если качалка не отличает штатное и нештатное закрытие сокета - это не проблемы протокола.
Даже если передача потоковая - существует Content-Range, который может использоваться как самостоятельно, так и в комбинации с Content-Length.И оверхед в 25% тоже является не то чтобы проблемой, но недостатком протоколаКак вы собрались получить хоть процент накладных расходов на передаче хоть сколько-нибудь крупных файлов?Угу :) То есть фактически начали руками закрывать дырку :)Какую дырку? Мне в любом случае требовалось сообщать где лежит файл, как он называется и какой у него размер.

P.S. Единственное преимущество ftp - существование "стандартного ftp-клиента".

softwarerИменно что "допустимо", а не "обязательно". В результате чего регулярно попадаются реализации, которые этого не делают.Вы опять путаете протокол с кривыми веб-приложениями.

maytonА разве нельзя было уведомлять разработчиков об изменении дампа по почте?У разработчика есть, условно говоря, баг-трекер.
У нас возникает проблема, мы её смотрим, сообщаем всю необходимую информацию и получаем ответ: "Нужен дамп".
При этом в работе может находится ещё пара-тройка инцидентов с таким же первоначальным откликом.
Об изменении какого дампа мы должны уведомить разработчика? И почему мылом? И даже если уведомить - почему я должен присылать листинг ftp-каталога вместо http-ссылки?

softwarerНе путаю. Протокол допускает кривые реализации, и это именно его недостаток. Кривые реализации регулярно встречаются, это реальная проблема. Из-за этой проблемы я не стал бы выбирать HTTP, поскольку решение получается не слишком надёжным.Поскольку альтернативой http выставляется ftp, то о динамическом контенте речи, наверное, не будет?
А если не будет, то и Apache httpd и Apache Tomcat формируют Content-Length для статического контента без дополнительного участия горе-программиста. Насколько я могу судить по документации nginx - он делает точно так же.
IIS, в последнее время как-то не попадался, но "меня опять терзают смутные сомнения", что и он делает точно также.
Кривые http-серверы, безусловно существуют и лично я даже читал о проблеме работы одной такой поделки и тогда же продемонстрировал, что у индейца нет "этой странной проблемы". Вот буквально за четверть часа собрал то, что не работало у вопрошавшего и выложил лог успешной работы клиента.
Т.е. ваш пример из серии: "А что будет, если и клиент и сервер находятся за NAT-ами, которые не имеют поддержки FTP?".
Да, такие ситуации бывают и мне даже доводилось на них попадать, но к технологии это никак не относится. Это относится к вполне конкретному рукопопию.

maytonКто-нибудь использовал в своих задачах HTTP методы PUT, DELETEТолько CONNECT в виде (готовой) реализации socks-прокси. Но это было лет десять назад.

softwarerПротокол допускает кривые реализации, и это именно его недостаток. Кривые реализации регулярно встречаются, это реальная проблема. Из-за этой проблемы я не стал бы выбирать HTTP, поскольку решение получается не слишком надёжным.И, кстати, замените фразу "HTTP протокол" на "реализация SQL-стандарта"

softwarerЯ несколько лет не пользовался http-качалками, может, ситуация изменилась. Пока пользовался - не возвращавшие content-length наблюдал регулярноОно и сейчас может "регулярно наблюдаться". Просто потому, что очередной гений программирования решил самостоятельно формировать HTTP-заголовки.
Я просто повторю, что это ни разу не проблема протокола - с дуру можно и дуб сломать.

softwarerИ что?При всех недостатках, обычно, не от SQL отказываются, а решают конкретные проблемы конкретной реализации. Причём по разному решают, т.к. серебряную пулю никто, вроде, не отлил.

Dima TНе делая своей серверной части (сайта или веб-приложения) полноценный обмен файлами по HTTP просто невозможен. Классическая настройка безопасности сервера дает пользователю (под которым работает веб-сервер) права только чтения к папке сайта.Вот только не надо путать настройки веб-сервера и его доступ к файловой системе.Т.е. ни веб-сервер, ни скрипт им запущенный при всем желании файл не запишет. Поэтому HTTP не заточен на прием файлов серверомТо, что криворукие программисты не освоили POST - их личная проблема.