Différence entre les types de contenu application / x-javascript et texte / javascript

245

Quelle est la différence entre ces en-têtes?

Content-Type: application/javascript
Content-Type: application/x-javascript
Content-Type: text/javascript

Laquelle est la meilleure et pourquoi?

Veuillez ne pas dire qu'ils sont identiques - s'ils étaient identiques, il n'y en aurait pas eu trois. Je sais que les deux fonctionnent - mais j'aimerais connaître la différence.

javascript http-headers content-type

— Obmerk Kronen
source

1

La différence est également une raison classique pour laquelle vos scripts ne sont pas compressés. Assurez-vous que vous disposez d'une entrée dans httpCompression pour le type réel que vous servez et notez que IIS Express compresse uniquement l'application / x-javascript et le texte / * par défaut.

— rism

NB: Une liste complète des "types de mime javascript" peut être trouvée ici: html.spec.whatwg.org/multipage/… . c'est-à-dire qu'il s'agit de la liste de valeurs qu'un navigateur doit autoriser pour scriptl' typeattribut d' une balise lorsque la nosniffdirective est spécifiée. developer.mozilla.org/en-US/docs/Web/HTTP/Headers/…

— JohnLBevan

320

text/javascriptest obsolète et application/x-javascriptétait expérimental (d'où le x-préfixe) pendant une période de transition jusqu'à ce qu'il application/javascriptpuisse être normalisé.

Vous devez utiliser application/javascript. Ceci est documenté dans le RFC .

En ce qui concerne les navigateurs, il n'y a pas de différence (au moins dans les en-têtes HTTP). C'était juste un changement pour que les groupes de types text/*et application/*MIME aient une signification cohérente dans la mesure du possible. (Les text/*types MIME sont destinés à un contenu lisible par l'homme, JavaScript n'est pas conçu pour transmettre directement un sens aux humains).

Notez que l'utilisation application/javascriptde l' typeattribut d'un élément de script entraînera l'ignorance du script (comme étant dans une langue inconnue) dans certains navigateurs plus anciens. Vous pouvez soit continuer à l'utiliser text/javascript, soit supprimer complètement l'attribut (ce qui est autorisé dans HTML 5).

Ce n'est pas un problème dans les en-têtes HTTP, car les navigateurs universellement (à ma connaissance) ignorent complètement le type de contenu HTTP des scripts ou sont suffisamment modernes pour être reconnus application/javascript.

— Quentin
source

merci beaucoup pour la réponse détaillée. un autre problème - vous avez dit que je pouvais l'omettre complètement (seulement HTML5?) - mais ma question (qui a ensuite été modifiée par quelqu'un) concernait spécifiquement JS en PHP - cela fonctionnera-t-il en tant que combo PHP / JS sur tous les serveurs / navigateurs si je l'omets entièrement ??

— Obmerk Kronen

8

Vous pouvez omettre l' type attribut sur un <script>élément. Vous ne pouvez pas omettre l' Content-Typeen-tête HTTP… jamais (si vous ne le spécifiez pas en PHP, PHP sera par défaut text/htmlce qui est très faux).

— Quentin

2

Suivant la logique lisible par l'homme, le CSS ne devrait-il pas être également classé sous application au lieu de texte?

— Fabrício Matté

2

@frnhr votre modification à cette réponse a changé la signification voulue (qui était de déclarer qu'elle text/javascriptest obsolète et application/x-javascriptexpérimentale). Pire encore, cela a laissé le début de la réponse incohérent, avec un bloc disant text/javascriptsimplement traîner sans pertinence en haut de la réponse sans raison évidente.

— Mark Amery

1

Dans SVN, utilisez définitivement text / javascript. SVN traite tout ce qui ne commence pas par text / comme binaire. Pour corriger l'intégralité de votre copie de travail SVN, vous devez créer un fichier mime.cmd contenant les éléments suivants: @echo off for /r . %%X in (*.js) do ( svn propset svn:mime-type text/javascript "%%X" ) qui, une fois exécuté, changera le type mime de tous les fichiers JS de votre référentiel en texte / javascript. Vous devez ensuite valider les fichiers JS sur SVN avec le nouveau type MIME.

— Mark Eldridge

21

les types mime commençant par x-ne sont pas standardisés. En cas de javascript, c'est un peu dépassé. Ajout du deuxième extrait de code

<?Header('Content-Type: text/javascript');?>

nécessite short_open_tagsd'être activé. vous devez l'éviter.

<?php Header('Content-Type: text/javascript');?>

Cependant, le type MIME complètement correct pour javascript est

application/javascript

http://www.iana.org/assignments/media-types/application/index.html

— KingCrunch
source

1

Ancienne réponse, mais je ne sais pas si c'est bien de commencer avec de courtes balises ouvertes jusqu'à ce que ce ne soit pas une bonne pratique (nous vous recommandons fortement de désactiver PHP-SOT en fait)

— Ben Cassinat

8

Selon la RFC 4329, le type MIME correct pour JavaScript devrait être application/javascript. Cependant, les anciennes versions d'IE s'étouffent à ce sujet car elles s'y attendent text/javascript.

— Björn
source

7

Pour autant que je sache, IE ne donne pas à un singe ce que dit le type de contenu HTTP; seulement ce que dit l' typeattribut HTML (et dans les brouillons HTML 5, cet attribut peut être omis pour JavaScript).

— Quentin

@Quentin ahh ... c'est ce qui me posait des problèmes. Merci!

— martin

3

Utilisez type = "application / javascript"

En cas de HTML5, l'attribut type est obsolète, vous pouvez le supprimer. Remarque: il est par défaut "text / javascript" selon w3.org, donc je suggère d'ajouter "application / javascript" au lieu de le supprimer.

http://www.w3.org/TR/html5/scripting-1.html#attr-script-type
L'attribut type donne la langue du script ou le format des données. Si l'attribut est présent, sa valeur doit être un type MIME valide. Le paramètre charset ne doit pas être spécifié. La valeur par défaut, qui est utilisée si l'attribut est absent, est "text / javascript".

Utilisez "application / javascript", car "text / javascript" est obsolète :

RFC 4329: http://www.rfc-editor.org/rfc/rfc4329.txt

Types de supports de script déployés et compatibilité

Divers types de supports non enregistrés ont été utilisés de manière ad hoc pour étiqueter et échanger des programmes écrits en ECMAScript et JavaScript. Ceux-ci inclus:

+ ------------------------------------------------- ---- + | texte / javascript | texte / ecmascript | | text / javascript1.0 | text / javascript1.1 | | text / javascript1.2 | text / javascript1.3 | | text / javascript1.4 | text / javascript1.5 | | text / jscript | texte / scénario de vie | | text / x-javascript | text / x-ecmascript | | application / x-javascript | application / x-ecmascript | | application / javascript | application / ecmascript | + ------------------------------------------------- ---- +

L'utilisation du type de niveau supérieur "texte" pour ce type de contenu est connue pour être problématique. Ce document définit ainsi text / javascript et text /
ecmascript mais les marque comme "obsolètes". L'utilisation de
types de supports expérimentaux et non enregistrés, comme indiqué dans la partie ci-dessus, est déconseillée.
Les types de médias,
  * application/javascript
  * application/ecmascript
qui sont également définis dans ce document, sont destinés à un usage courant et doivent être utilisés à la place.

Ce document définit des exigences de traitement équivalentes pour les
types text / javascript, text / ecmascript et application / javascript.
L'utilisation et la prise en charge de l'application / ecmascript de type de support sont
considérablement moins répandues que pour les autres types de support définis dans
ce document. Utilisant cela à son avantage, ce document définit
des règles de traitement plus strictes pour ce type afin de favoriser un
traitement plus interopérable .

x-javascript est expérimental, ne l'utilisez pas.

— juFo
source