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

softwarerЭмм... эта точка зрения как минимум не самая распространённаяМогу только плечами пожать.
С таким подходом и PPP - плохой протокол, поскольку там даже MIME-типов нет.

softwarerЛично я не понимаю, почему если я делаю telnet на двадцатый порт и набираю команды, то я попадаю в протокол прикладного уровня, а если делаю на восьмидесятый и набираю другие команды - то в транспортногоДавайте предадим анафеме все общеизвестные порты, окромя двадцать первого. Какая, в конце-концов, проблема выбрать протокол общения по запросу от клиента или прочитать возможности сервера по строке приветствия?
Ну а если серьёзно, то укажите, пожалуйста, какую прикладную задачу решает HTTP? Если подойти к вопросу непредвзято, то это именно транспорт.

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

softwarerНу, если не ходить далеко, то она написана в названии - гипертекст трансферВот именно - передача.
При этом для разметки гипертекста HTTP опирается на MIME-RFC, хотя и с некоторыми девиациями.Ровно как FTP решает прикладную задачу файл трансфер. И даже это подсказывает, что разумнее выбрать для задачи файл трансфера И, опять-таки, я ещё раз озвучу свою позицию:
Я не возражаю против использования FTP для передачи файлов, но категорически против формулировки "HTTP - хуже" или "HTTP - непродуманный протокол". HTTP - гибкий протокол, который в состоянии решить практически любую транспортную задачу. В том числе - беспроблемную передачу больших двоичных файлов.

Вы же начинаете предъявлять к протоколу странные претензии. Совершенно необоснованные.
Точно таким же образом я могу предъявить высосать из пальца претензию авторам FTP протокола, которые неточно определили сценарии получения файлов, что иногда приводит к невозможности использовать, например, wget в качестве FTP-клиента. Претензия из такой же реальной жизни, как и ваша.Если подойти к вопросу разумно, то надо дать определения "транспорта", "прикладного" итп. Лично мне очевидно, что Вы пользуетесь какими-то своими определениями, отличающимися от определений авторов TCP-стека.А почему, собственно, мы буквоедствуем в рамках модели IP-сетей?Также у меня есть ощущение, что разница, которую Вы видите, обусловлена тем, что с HTTP Вы привыкли общаться через оболочку (браузер), а про FTP привыкли думать как про "безоболочечный" (хотя никто не мешает стукнуться к нему через тот же браузер).Не знаю, на чём основано ваше ощущение, но оно ошибочно.

softwarerС этой точки зрения и FTP - транспортныйНет. Именно в силу заточенности на конкретную прикладную задачу. И в силу того, что требования к каналу передачи самые общие - "прозрачный" восьмибитный.
И наоборот. HTTP не конкретизирует прикладную задачу, но детально описывает обмен сообщениями, использование посредников и кучу "транспортных" деталей.
Поэтому буквоедство в стиле "оба протокола прикладные, т.к. находятся на верхнем уровне моделей IP/ISO" формально, да - правильное, но бесполезное.Когда я её нашёл, я полез в стандарт ANSI, и прочитал там, что мать его такА ещё стандарт не определяет конкретный порядок вычисления аргументов функции и допускает другие неоднозначности. Только это ни разу не проблема стандарта.
Есть ситуации, когда меня более чем устраивает возможность написать:
И лично я слабо понимаю, зачем лезть в стандарт? Неопределённость префиксных и постфиксных операторов упомянуты, вроде, в любом учебнике.Но то, что стандарт допускает подобное разночтение, я считаю конкретным косяком стандарта"Компилятор языка C служит для трансляции исходного текста в объектный код. Хотите персональных ремней безопасности - программируйте на языке ADA".
Как говорится - ни убавить, ни прибавить.Вы пытаетесь объяснить мне, что стандарт хорошийЯ пытаюсь донести до вас ту простую мысль, что приведённые вами примеры "недостатков" HTTP - неудачны. Мягко говоря.Я не очень понимаю, о чём ВыЕсть два варианта получить файл:
1. Сделать get /абсолютный/путь/файл
2. Сменить удалённый каталог и сделать get файл
Так вот, прав на каталог может не быть, а в стандарте эта неопределённость никак не отражена.По дефолту. Хотите уйти от дефолта - давайте свои определения, и не забудьте упомянуть, что Вы говорите о "транспортном по-сидоровски" протоколе."Не держись устава, яко слепой стены". Когда мне потребуется рассмотреть все уровни модели - я воспользуюсь вашей рекомендацией.
До тех пор, пока мы остаёмся на (только) верхнем уровне модели - я имею полное право различать разные классы выскоуровневых протоколов. Именно в силу того, что они находятся на одном уровне, но решают разные задачи.