При обслуговуванні файлів JavaScript краще використовувати додаток / javascript або application / x-javascript

95

Ціле питання вміщується в назві. І щоб додати деякий контекст: я не запитую, що найкраще відповідно до того, що говорять специфікації, а саме те, що найкраще працює, враховуючи поєднання браузерів, розгорнутих сьогодні.

Деякі точки даних:

  • Google використовує text/javascript для JS, що використовується на їх домашній сторінці.
  • 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атрибут з елементів сценарію

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

— Квентін
джерело
3
Це питання від кількох місяців тому говорить прямо протилежне. Хтось помиляється :) "Келлі правильно, браузери, як правило, довіряють типу MIME, надісланому заголовками відповідей, над атрибутом type тегу сценарію" stackoverflow.com/questions/189850/…
— Марко
6
О ні! Великі, монолітні, повільні організації повинні мати рацію! Специфікація повинна бути неправильною! Нархх. Я продовжуватиму довіряти специфікації та власному досвіду у великих (повільних) компаніях, навіть якщо одна з них раніше працевлаштовувала мене.
— Квентін
1
Хм, хтось забув сказати W3C, що текст / javascript застаріли. Здається, це за замовчуванням у HTML 5 . :: scratches head :: Також здається (якщо моє побіжне прочитання цього розділу є правильним), що користувацькі агенти повинні переходити лише за typeатрибутом, таким чином ігноруючи Content-typeправильну поведінку.
— big_m
1
@big_m - Це тому, що багато браузерів не розпізнають, application/javascriptтому, вказавши це, вони будуть ігнорувати сценарій. Агенти користувачів не повинні ігнорувати Content-Type. Атрибут type говорить їм, чого очікувати. Якщо вони цього не підтримують, їм не слід турбуватися про це. Якщо сервер тоді скаже, що це щось інше, вони повинні продовжувати це, а не те, що говорить HTML (принаймні згідно з HTTP, ви можете дивитись на іншу специфікацію, ви не надали жодних посилань).
— Квентін
1
@Quentin, я мав на увазі розділ HTML 5 про scriptелемент, до якого я посилався . Моє прочитання цього розділу відрізняється від того, що ви описуєте; здається, це приділяє велике значення typeатрибуту і не згадує про перевірку Content-Type, за винятком визначення кодування символів. Я погоджуюсь з тим, що, здається, було б розумно для користувацького агента перевірити, чи відповідає Тип вмісту тому, що очікується, але в специфікації HTML я не знайшов нічого, що вимагає або навіть рекомендує це робити.
— big_m
7

Якщо ви вирішите використовувати додаток / javascript для js на своїх сторінках, IE7 та IE8 не запускатимуть ваш сценарій! Звинувачуйте Microsoft у всьому, що вам потрібно, але якщо ви хочете, щоб більшість людей запускали ваші сторінки, використовуйте текст / javascript.

— Дрю Б
джерело
3
Коли ви говорите, що "application / 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) явно виправляє.

— Матіас Байнс
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.