#http #firefox #browser #download #http-headers
#http #firefox #браузер #Скачать #http-заголовки
Вопрос:
Мое веб-приложение создает zip-файл для загрузки файлов, связанных с экземпляром «Задачи». Этот zip-файл может содержать изображения, файлы .pdf или .txt, созданное имя файла имеет вид «{TaskName}.taskBundle».
Чтобы загрузить файл, веб-приложение использует следующие заголовки в ответе (из Firefox Network monitor):
Content-Disposition: attachment; filename="task1.taskBundle"
Content-Type: application/zip;charset=UTF-8
Проблема:
Используя Firefox 84.0 (версии Ubuntu и Windows), браузер заменяет расширение «.taskBundle» на «.zip», поэтому загруженное имя файла «task1.zip » вместо «task1.taskBundle».
Я попытался загрузить тот же файл с помощью Chrome (87.0) и других версий Firefox (83.0, 82.0, 80.0, 74.0), и имя файла правильное: «task1.taskBundle».
Может быть, мне следует добавить другой заголовок в ответ, чтобы Firefox не изменил расширение файла?
Я могу изменить тип содержимого на «application / octet-stream», но флажок «С этого момента делать это автоматически для таких файлов». не отображается в диалоговом окне загрузки.
Дополнительные примечания: Мое приложение написано с использованием Grails 3.3.9, но я думаю, что это не проблема Grails, потому что заголовки ответов отправляются клиенту, как описано ранее.
Ответ №1:
Мы исправляем это в https://bugzilla.mozilla.org/show_bug.cgi?id=1684183 , но, скорее всего, это будет не раньше Firefox 85 (т. Е. Мы не будем отправлять исправление безопасности / выхода из цикла dot-release только для решения этой проблемы).
Более простым обходным путем для вашего использования было бы выбрать / стандартизировать определенный mimetype для этих «пакетов задач», application/x-my-fancy-application-task-bundle например, если вы не хотите, чтобы UA обрабатывал его как zip-файл.
Как Firefox, так и другие браузеры могут принять решение действовать в соответствии с типом mimetype (например, в случае Firefox мы показываем опции «Открыть в Firefox», если вы отправляете application/pdf или SVG-типы mimetypes, даже для Content-Disposition: attachment ответов, чтобы упростить немедленное открытие содержимого). В Chrome есть специальные проверки application/zip при прослушивании.
Регрессивное изменение здесь было частью исправления для обработки веб-серверов, с которых отправляются foo.jpg файлы Content-Type: image/webp , когда пользователи жаловались, что результирующие .jpg файлы на самом деле не являются файлами jpeg. Поэтому мы добавили нормализацию расширений для нескольких разных типов mimetypes. Я ошибочно предположил, что application/zip файлы будут, как вы знаете, zip-файлами и могут обрабатываться как таковые.
Ответ №2:
Возможно, вы захотите сообщить об этом на сайте Mozilla Bugzilla (https://bugzilla.mozilla.org ) в Firefox, так как я не могу найти отчет, описывающий именно это поведение. Похоже, что они что-то сломали в последней версии (трудно сказать, была ли это ошибка или функция), поскольку я заметил такое поведение и на сайте с несоответствующим типом содержимого.
Конечно, если бы это было преднамеренное изменение, это был бы не первый случай, когда Mozilla игнорирует веб-стандарты, чтобы делать все «по-своему». Меня по-прежнему бесконечно раздражает, что мне приходится использовать 5-слэш, чтобы ссылки на файловые протоколы открывались правильно, когда в стандартах четко указано иное (см.: https://bugzilla.mozilla.org/show_bug.cgi?id=992123 )