Comments 62
А в чём смысл? Вообще, что за безумный общий тренд последнего времени в разработке ПО, когда непонятно зачем урезается функционал, существующий десятилетиями и прекрасно до того работавший?
прекрасно до того работавшийЭто совсем не про FTP в Firefox. В текущем состоянии поддержка FTP в Firefox это чемодан без ручки.
1) в Firefox нет поддержки FTPS, т.е. FTP-трафик гоняется по небезопасному соединению со всеми вытекающими в виде MitM-атак и слива перехваченных данных.
2) в Firefox невозможно скачать по FTP каталог (т.е. если вам нужно скачать каталог или, пуще того, вложенные каталоги, то качайте по одному файлу)
3) в Firefox невозможно загрузить файлы по FTP, оно работает лишь на скачивание.
Можно констатировать, что поддержка FTP находится в зачаточном состоянии и пригодна лишь для того, чтобы скачать один конкретный файл (как только нужно скачать больше или закачать — вы идёте искать сторонний клиент)
4) эта поддержка реализовывалась в доисторические времена, код очень древний, довольно кривой (отчего неоднократно находили уязвимости), его тяжело поддерживать, нужен рефакторинг
Нужно всё переписывать с нуля, попутно реализуя указанные выше возможности. Но, с учётом того, что популярность FTP «сейчас» гораздо ниже, чем «тогда», и того, что эта популярность неуклонно снижается год от года, встаёт вопрос, а почему нужно бросить силы именно на FTP? Например, BitTorrent или SCP/SFTP (операции с файлами поверх SSH) намного популярнее. Но нужно ли тащить в браузер торренты и SSH? Не лучше ли использовать отдельное полнофункциональное приложение? Именно так и решили поступить — схему ftp:// можно будет ассоциировать с любым сторонним клиентом, коих в избытке.
Но нужно ли тащить в браузер торренты и SSH? Не лучше ли использовать отдельное полнофункциональное приложение?
А как насчёт видео проигрывателя и прочего webgl, может быть тоже лучше отдельное полнофункциональное приложение?
Но с видео ситуация сложная: не на всех сайтах у вас получится открыть видео во внешнем проигрывателе.
Выпадают доходы от рекламы? Я вот слушаю радио через стороннее приложение — а мог бы прямо с сайта слушать и мне бы откручивалось бы несколько десятков баннеров в минуту — а я негодяй мешаю заработать.
Справедливости ради, в бегающих ip-адресах нет ничего плохого. В том же HTTP может быть запросто
GET / HTTP/1.1
Host: 127.0.0.1и всё хорошо.
Вот где всё взорвалось — это на NAT'ах, конечно. Но это проблема NAT'ов. Классическая модель сети никаких NAT'ов не подразумевала и осуждала. Есть адрес в сети? Есть коннективити. Не хочешь коннективити? Блокируй.
Протокола передачи файлов, который поддерживается так же хорошо, как FTP, не существует (либо я о нем не знаю). Его преимущество в настоящее время только в универсальности: до начала этого года он поддерживался в любой операционной системе и браузере, без установки дополнительного ПО.
Посмотрите мои аргументы:
https://groups.google.com/d/msg/mozilla.dev.platform/FqCZUT9ay_o/mCVGFuyfBQAJ
И нет, тот факт что в домашних роутерах бубен для FTP входит в комплект поставки — нифига не нормально. Каменный топор почему-то не выдают.
Не понимаю, о чем вы: держу несколько FTP-серверов за NAT много лет, всё работает. И серверы, и клиенты. В отличие от современного ПО, для FTP нужно пробросить не только 21 порт, но и еще дополнительные пассивные. Это единственное отличие и дополнительное действие. Настроек на клиентах не требуется.
FTP, может, не плох, но речь о его реализации в Firefox, которая откровенно никакая. Ваши аргументы по ссылке они, опять таки, в пользу протокола в целом. Например «You can download and upload whole folders» — для этого как раньше приходилось ставить сторонний клиент, так и дальше придётся. Браузер этого не умеет.
В итоге, мы приходим к тому, о чём я писал выше: текущую недореализацию в любом случае придётся убить — либо для того, чтобы написать с нуля полноценную поддержку FTP, либо для того, чтобы выкинуть FTP из браузера вовсе. А писать полноценную поддержку нет смысла из-за низкой востребованности.
Я храню и раздаю файлы через FTP, потому что он очень простой в настройке, и с ним легко выдавать людям доступ на загрузку (upload). Люди с любым браузером могли найти файлы на FTP через Google и скачать, теперь они будет либо качаться в отдельной программе, либо вовсе не будет.
Google до сих пор индексирует FTP, он считается частью веба, хоть и совсем не веб.
FTP как протокол не люблю, реализацию его в браузерах не защищаю, но раз уж исторически реализовали его во всех браузерах, то будьте добры поддерживать. Любой альтернативный протокол поддерживается хуже, его нельзя использовать массово, в отличие от FTP (до недавнего времени).
FTP удаляют, не предлагая альтернативы, вынуждая использовать две сущности: протокол для операции с файлами и HTTP-сервер для их раздачи, когда раньше можно было обойтись одной, в виде FTP.
WebDav поддерживается, насколько знаю, только в IE. Других «браузерных» протоколов передачи файлов просто не существует.
К слову, удаление поддержки FTP из Firefox и Chrome задержали на год из-за пандемии. Обосновывали тем, что государственные сайты до сих пор выкладывают файлы на FTP-серверы. Как эти два факта вяжутся — загадка, то ли пандемия закончилась, то ли людям FTP нужен был только в пандемию.
FTP как протокол не люблю, реализацию его в браузерах не защищаю, но раз уж исторически реализовали его во всех браузерах, то будьте добры поддерживатьGopher тоже надо было поддерживать? А то я знаю одного веб-мастера, который его до сих пор поддерживает на своём сервере. То есть, вместо того, чтобы отменить, наконец, неудачное решение, нужно затратить ещё больше сил и писать полноценную поддержку протокола с нуля ради полупроцента пользователей.
Вообще, довольно странная позиция — «нельзя избавляться от легаси».
К слову, удаление поддержки FTP из Firefox и Chrome задержали на год из-за пандемии. Обосновывали тем, что государственные сайты до сих пор выкладывают файлы на FTP-серверы. Как эти два факта вяжутся — загадка, то ли пандемия закончилась, то ли людям FTP нужен был только в пандемию.Мне кажется, что всё проще — ждали, пока Chrome сделает шаг.
Gopher тоже надо было поддерживать? А то я знаю одного веб-мастера, который его до сих пор поддерживает на своём сервере.
Мне не приходилось пользоваться Gopher, я не знаю, насколько он был распространён. Но FTP-серверов — море, я пользуюсь протоколом так или иначе ежедневно, тут и там попадаются ссылки, начинающиеся на ftp://
Вы не замечаете, потому что они у вас просто работают.
Мне кажется, что всё проще — ждали, пока Chrome сделает шаг
Chrome удалил поддержку FTP, потом началась пандемия, они её вернули, и вот, спустя год, еще раз удалили.
https://habr.com/ru/news/t/497352/
Компания объяснила откат необходимостью обеспечить пользователям стабильный доступ к информации во время пандемии.
Многие правительственные учреждения, в том числе национальные институты здравоохранения по-прежнему используют сайты FTP.
Хочется верить, что Google связался с сайтами, заставил администраторов значительных ресурсов сделать доступ по HTTP, и спустя год необходимость в FTP-доступе стала меньше для подавляющего большинства пользователей. Но, уверен, это не до конца так.
Если у WebDAV нет каких-нибудь фундаментальных проблем, то по-моему лучше пропагандировать расширение его поддержки, чем держаться за жуткое легаси
Браузеру не обязательно встраивать внутренний файловый менеджер, но обеспечить простой браузинг директории и скачивание отдельного файла по ftp — реализуется грамотным разработчиком за пару вечеров.
Возможность скачать один файл по ссылке через браузер — востребована. Например ftp быстрее чем http (1.0) процентов на 30.
WebDAV реализовывать вообще толком не нужно, потому что он основан на HTTP, который и так уже реализован в каждой лампочке
Скорость никак не может зависеть от протокола. Или вы хотите сказать, что если я качаю файл по http со скоростью 100 Мбит/с, то при переходе на ftp случится ЧУДО и каким-то образом получится обойти фундаментальные ограничения Fast Ethernet?
Или вы хотите сказать, что если я качаю файл по http со скоростью 100 Мбит/с, то при переходе на ftp случится ЧУДО и каким-то образом получится обойти фундаментальные ограничения Fast Ethernet?
Попробуйте скачать видеофайл, например .mkv и померяйте. А я потом расскажу где именно находится фундаментальное ограничение.
Дайте ссылку, попробую скачать. Только без шейпера.
Но для начала — http — это текстовый протокол, он не умеет в binary mod.
http — это текстовый протокол, он не умеет в binary mod.
Да в общем-то можно и в RFC 1945 заглянуть и увидеть, что ещё в HTTP/1.0 повсюду (к примеру, разделы 2.2, 7.2, приложение C.4) используются именно октеты, то есть он всегда был вполне себе бинарный и никогда не был MIME-совместим
Люди с любым браузером могли найти их через Google и скачать, теперь он будет либо качаться в отдельной программе, либо вовсе не будет.Ранее, при предложениях выпилить FTP, уже поднимали этот вопрос. Мне кажется, что этот функционал можно легко и быстро перевоплотить с помощью веб-сервера с листингом файлов в директории (autoindex).
Протокола передачи файлов, который поддерживается так же хорошо, как FTP, не существует (либо я о нем не знаю)SFTP, SCP, SSHFS на выбор.
SFTP поддерживается преимущественно в специализированном ПО. В медиаплеерах, просмотрщиках картинок, файловых менеджерах вы его почти не встретите. Широкоиспользуемые серверы не поддерживают анонимный режим доступа. Сложный в реализации нижележащий протокол SSH, с собственной концепцией каналов и инкапсуляции данных в одно соединение. У наиболее популярного сервера (и клиента тоже, наверное) OpenSSH вековые проблемы с сетевой производительностью, требующие сторонних патчей для высокой скорости.
SCP — устаревший плохой протокол, примитивная программа scp, функция ровно одна (скопировать один файл), нигде не поддерживается.
SSHFS — вообще не протокол, а программа для монтирования SFTP.
Очень простой и надежный протокол. Единственный его минус — открытый и небезопасный. Но для анонимус доступа — самый быстрый.
самый быстрый
Файлы с, например, ftp.ru.debian.org скачиваются по ftp и http с абсолютно одинаковой скоростью (у меня получилось 400 Мбит/с, а на VDS и ftp.nl.debian.org вообще целый гигабит), протокол здесь вообще ни при чём
Вы поставьте рядом два компа, соедините проводом и потестируйте скорость непосредственно протокола. Или банально спецификацию глянуть, из которой следует, что в ftp, например, есть бинарный режим передачи данных, а в http — его нет (появляется только в http 2.0, который в инете еще надо днем с огнем поискать).
в конкретом сайте или маршрутизации до него, где могут шейпить трафик
Ну вот вы сами и подтвердили, что протокол здесь ни при чём
… бинарный режим передачи данных, а в http — его нет
А здесь вы показываете своё незнание матчасти. В http ВСЕ данные передаются в бинарном виде, а в http/2 всего лишь добавили более эффективную упаковку заголовков, мультиплексирование и прочие мелкие оптимизации
Делать одну вещь, но делать её отлично. Это, напомню, принцип unix. Про FF трудно сказать про "одну вещь", но сконцентироваться на http/https вместо "странных протоколов" очень разумно.
У ftp другая модель работы, лучше использовать более подходящие для этого инструменты.
Последний раз, когда я проверял — встроенный FTP-клиент даже отсылать данные на сервер не мог, по крайней мере этого не было предусмотрено в интерфейсе. Да и в целом, для FTP есть другие клиенты, неясно зачем было добавлять это в браузер.
Плюс новая стратегия Mozilla, которая заключается в том, что «полуфабрикаты», у которых нет перспектив доведения до вменяемого состояния, идут под нож. Great or dead. Из примеров: TCP Fast Open (прожившая пару релизов, а затем отключенная на годы, т.к. вызывала проблемы с некоторыми маршрутизаторами) и PWA (там всё вышло настолько глючно, что её так и не решились включить).
Скорее, что бывает иногда, что натыкаешься на ftp ссылку для скачивания файла и теперь надо будет потратить минут на 5 больше времени для установки filezilla.
Ссылки в списке зеркал загрузки дистрибутивов от Apache, если правильно помню. Там могут быть и http и ftp ссылки. Например вот: https://www.apache.org/dyn/closer.cgi/hadoop/common/hadoop-3.2.2/hadoop-3.2.2.tar.gz
Я вмешаюсь: HP. Крупный вендор у которого очень удобно скачивать все по FTP.
ftp://ftp.hp.com/pub/ и ftp://ftp.itrc.hp.com/ — дико удобно когда надо скачивать кучу SP-шек.
FTP — давно уже функция файловых менеджеров.
Чтобы компенсировать удаление поддержки ftp он был добавлен в список поддерживаемых обработчиков протоколов для расширений браузера. Это означает, что расширения смогут предлагать пользователям запустить приложение FTP для обработки определенных ссылок.Расширения тут не при чём. Любое стороннее приложение может зарегистрировать себя в системе в качестве обработчика того или иного протокола, расширения для этого не требуются. Будет так же, как, например, с magnet:// — если в системе есть приложение, зарегистрировавшее себя в качестве обработчика magnet://, браузер выплюнет окошко с предложением открыть ссылку этим предложением (и опционально делать это в дальнейшем автоматически).
А как теперь будет все это реализовываться? Ну вот сайт хочет показать свою внутреннюю структуру файлов для скачивания, то пользователь должен будет через sftp клиент качать? А если пользователь "дуб'с"? Ну и не удобно это, переписали бы код с нуля постепенно.
p.s Для меня самое главное чтобы в SeaMonkey поддержку ftp не выпилили.
Все правильно. Для ftp есть filezilla и ему подобные.
Тащить функционал которым пользуется 0.1% пользователей — бессмысленная трата ресурсов на поддержку и сопровождение. Плюс лишние потенциальные дыры.
Вообще не понимаю, зачем ftp в браузере. В тотал коммандере отличный клиент. Да что говорить, — даже Проводник умеет в фтп.
Встроенная поддержка FTP будет удалена в Firefox 90