При обслуживании файлов JavaScript лучше использовать application / javascript или application / x-javascript

95

Весь вопрос укладывается в заголовок. И чтобы добавить некоторого контекста: я не спрашиваю, что лучше всего в соответствии со спецификациями, а скорее, что работает лучше всего с учетом сочетания браузеров, развернутых в настоящее время.

Некоторые данные:

  • Google использует text/javascriptJS на своей домашней странице.
  • Google использует text/javascriptв Google Документах.
  • Google использует application/x-javascriptфайлы JavaScript для обслуживания своих библиотек Ajax .
  • Yahoo использует application/x-javascriptдля обслуживания своего JS.
  • Yahoo использует application/x-javascriptJavaScript, отображаемый на их домашней странице.
javascript http content-type avernet
источник
4
Веселая. В своих примерах вы приводите третью альтернативу ... И, по словам Тима, оба крупных игрока ошибаются (в отношении стандартов), что, вероятно, означает только то, что браузеры терпимы (здесь нет больших новостей), и это может не иметь значения.
PhiLho
1
возможный обман: Тип MIME Javascript
Берги

Ответы:

115
  • text/javascript устарело
  • application/x-javascript был экспериментальным, когда решал переехать в…
  • application/javascript это текущий официальный тип MIME для JS

Тем не менее, браузеры часто игнорируют content-typeотправленные сервером и уделяют много внимания typeатрибуту (а некоторые еще не распознают application/javascript).

Моя рекомендация:

  • Используйте приложение / javascript на сервере
  • Используйте HTML 5 и опустите typeатрибут из элементов скрипта

NB: спецификация HTML противоречит стандарту MIME, и есть попытки вернуть его обратно, text/javascriptчтобы это могло измениться в будущем.

Квентин
источник
3
Этот вопрос, поставленный несколько месяцев назад, говорит об обратном. Кто-то ошибается :) «Келли права, браузеры склонны доверять типу MIME, отправляемому с заголовками ответа, а не атрибуту типа тега скрипта» stackoverflow.com/questions/189850/…
Марко
6
о нет! Большие, монолитные, медленные организации должны быть правы! Спецификация должна быть неправильной! Нархх. Я буду по-прежнему доверять спецификации и моему собственному опыту в отношении крупных (медленных) компаний, даже если одна из них использовала меня.
Квентин
1
Хм, кто-то забыл сказать W3C, что текст / javascript устарел. Кажется, это значение по умолчанию в HTML 5 . :: царапает голову :: Также кажется (если мое поверхностное прочтение этого раздела верно), что пользовательские агенты должны работать только с typeатрибутом, таким образом игнорируя Content-typeповедение, было бы правильным.
big_m
1
@big_m - это потому, что многие браузеры не распознают его, application/javascriptпоэтому его указание заставит их проигнорировать скрипт. Пользовательские агенты не должны игнорировать Content-Type. Атрибут type сообщает им, чего ожидать. Если они его не поддерживают, им не следует беспокоиться об этом. Если сервер затем говорит, что это что-то другое, они должны продолжать это, а не то, что говорит HTML (по крайней мере, в соответствии с HTTP, вы можете смотреть на другую спецификацию, вы не предоставили никаких ссылок).
Квентин
1
@Quentin, я имел в виду раздел HTML 5 по scriptэлементу, на который я ссылался . Мое прочтение этого раздела отличается от того, что вы описываете; он, кажется, придает большое значение typeатрибуту и ​​не упоминает о проверке Content-Type, за исключением определения кодировки символов. Я согласен с тем, что для пользовательского агента было бы разумно проверить, соответствует ли Content-Type ожидаемому, но я не нашел в спецификации HTML ничего, что требует или даже рекомендует это делать.
big_m
12

В большинстве случаев тип mime, который отправляет сервер, практически не имеет значения. Я бы выбрал application / javascript , который также рекомендован RFC.

Мэтью Флашен
источник
7

Если вы решите использовать приложение / javascript для js на своих страницах, IE7 и IE8 не будут запускать ваш скрипт! Во всем вините Microsoft, но если вы хотите, чтобы большинство людей запускало ваши страницы, используйте текст / javascript.

Дрю Б
источник
3
Когда вы говорите, что «приложение / javascript» не будет работать, вы имеете в виду, если он установлен как тип содержимого в HTTP-ответе или как атрибут «type» тега скрипта? Первоначальный вопрос касался типа содержимого HTTP-ответов. Основываясь на других ответах, похоже, что только значение атрибута «type» в тегах скрипта будет иметь значение в любом случае в IE.
Джесси Халлетт
7

Раньше было language="javacript". Затем он изменился на type="text/javascript". Теперь это так type="application/javacript". Хорошо, это становится немым. Некоторые старые браузеры не распознают новые application/javascript, но все же распознают старые text/javascript. Я планирую продолжать использовать это, иначе я потрачу часы своего времени, пытаясь заменить КАЖДЫЙ экземпляр text/javascriptна application/javascript.
Теперь когда-нибудь может случиться обратное. Когда-нибудь новейшие браузеры могут отвергнуть старую технику, чтобы соответствовать строгим стандартам.
Но пока люди, просматривающие мой веб-сайт, не начнут жаловаться, что «с момента обновления моего браузера около 50% вашего веб-сайта исчезло», у меня нет мотива менять код на моем веб-сайте.

Sandip Armal Patil
источник
7

Вот ответ на этот вопрос в 2020 году.

text/javascript- это правильный тип MIME для JavaScript в соответствии со стандартом HTML , в котором говорится:

Серверы должны использовать text/javascriptресурсы JavaScript. Серверы не должны использовать другие типы MIME JavaScript для ресурсов JavaScript и не должны использовать типы MIME, отличные от JavaScript.

А также :

[…] MIME-тип, используемый для ссылки на JavaScript в этой спецификации text/javascript, - это наиболее часто используемый тип, несмотря на то, что он официально считается устаревшим в соответствии с RFC 4329.

Ведется работа по отражению этой реальности в RFC на уровне IETF: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Любое заявление о том, что « text/javascriptявляется устаревшим», основывается на RFC 4329, который явно исправляется как в стандарте HTML, так и в упомянутом выше проекте IETF (то есть в предстоящем RFC).

Матиас Байненс
источник