La différence entre application/x-javascript et text/javascript types de contenu

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

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

Lequel est le meilleur et pourquoi?

S'il vous plaît ne dis pas qu'ils sont identiques s'ils étaient identiques, il n'aurait pas été de trois d'entre eux. Je sais à la fois le travail - mais je voudrais savoir la différence.

La différence est également un classique de la raison pour laquelle vos scripts ne sont pas compressés. Assurez-vous que vous avez une entrée dans httpCompression pour le type réel vous servir et de noter que IIS Express comprime seulement application/x-javascript et le texte/* par défaut.
NB: UNE liste complète des "javascript types mime" peut être trouvé ici: html.spec.whatwg.org/multipage/.... c'est la liste de valeurs qu'un navigateur doit permettre une script de la balise type attribut lorsque le nosniff directive est spécifiée. developer.mozilla.org/en-US/docs/Web/HTTP/Headers/...

InformationsquelleAutor Obmerk Kronen | 2012-03-12

312

text/javascript est obsolète, et application/x-javascript était expérimentale (d'où le x- préfixe) pour une période de transition jusqu'à ce que application/javascript pourrait être standardisé.

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

En ce qui concerne les navigateurs sont concernés, il n'y a pas de différence (au moins dans les en-têtes HTTP). C'était juste un changement de sorte que la text/* et application/* type MIME groupes avait une constante sens où c'est possible. (text/* Types MIME sont destinés lisible par l'homme de contenu, JavaScript n'est pas conçu pour transmettre directement un sens pour l'homme).

Notez que l'utilisation de application/javascript dans le type attribut d'un élément script va provoquer le script pour être ignoré (comme dans une langue inconnue) dans certains navigateurs plus anciens. Soit continuer à utiliser text/javascript il ou omettre l'attribut entièrement (ce qui est autorisé en HTML 5).

Ce n'est pas un problème d'en-têtes HTTP, comme les navigateurs universellement (pour autant que je suis au courant), soit ignorer le HTTP content-type de scripts entièrement, ou modernes sont capables de reconnaître les application/javascript.
- merci beaucoup pour la réponse détaillée . encore une question - vous avez dit que je peux l'omettre entièrement (uniquement en HTML5 ? - mais ma question (qui plus tard a été modifié par quelqu'un) a été spécifiquement sur les JS en PHP ça va fonctionner comme PHP/JS combo sur tous les serveurs/navigateurs si je vais omettre entièrement ??
- Vous pouvez omettre le type attribut sur un <script> élément. Vous ne pouvez pas omettre le Content-Type en-tête HTTP ... jamais (si vous ne spécifiez pas en PHP, alors PHP par défaut text/html qui est très mauvais).
- Grâce - c'est ce que je pensais - je me demande pourquoi @Juhana édité il - elle peut produire des réponses différentes . Mais de toute façon - merci encore !
- À la suite de la lisible par l'homme, de la logique, ne devrait pas CSS être classées en vertu de l'application ainsi au lieu de texte?
- Oui, mais comme JS il a été mis en avant le "human readable" bit a été ajouté à text/ et contrairement à la JS personne n'a souciait assez pour faire le travail pour obtenir, elle a changé.
- SVN utilise également des types mime, qui sont affectés par fichier. Donc, si application/x-javascript est affecté, puis interne diff refuse de montrer les diff, se plaignant d'une entrée binaire. Voulez-vous suggérer d'utiliser text/javascript pour SVN?
- Je vous suggère de ne pas utiliser SVN. Je trouve Git et le Bazar beaucoup plus conviviale.
- votre modifier pour cette réponse changé le sens voulu (qui était de dire que text/javascript est obsolète et application/x-javascript était expérimentale). Pire, il a laissé le début de la réponse incohérente, avec un bloc en disant text/javascript juste traîner irrelevantly au sommet de la réponse pour aucune raison évidente.
- SVN, certainement utiliser text/javascript. SVN traite rien ne démarre PAS avec le texte/ binaire. Pour résoudre l'ensemble de votre SVN copie de travail, vous devez créer un mime.cmd fichier contenant le texte suivant: @echo off for /r . %%X in (*.js) do ( svn propset svn:mime-type text/javascript "%%X" ) qui lorsqu'elles sont exécutées, changer le type mime de tous les fichiers JS dans votre référentiel text/javascript. Ensuite, vous aurez à engager la JS fichiers SVN avec le nouveau type mime.
- référencé dans la RFC fichier est nulle part parler de Content-Type ou la relation à l'adresse HTTP. En outre, son statut dit: "Il ne spécifie pas un standard Internet de toute nature.". En fait, je n'ai pas trouvé tout RFC est en disant: "vous devez utiliser ceci ou cela", dans le contexte de javascript et Content-Type. D'autre part, certains Rfc et MDN dit que application/* est prévu pour tout type de données binaires et text/* pour le texte qui est "théoriquement lisible par l'homme"
- référencé dans la RFC décrit le régime enregistré type de média. Le RFC pour HTTP dit que la valeur de l'en-tête content-type est un type de média. Le type de média RFC n'est pas spécifiquement mention HTTP parce que beaucoup de autres choses, l'utilisation de types de médias (par exemple, SMTP et MIME à plusieurs parties). Les programmes JavaScript ne sont pas but pour être lu par les hommes, ils sont des morceaux de logiciel. Ils ne sont pas conçus pour transmettre des informations directement aux gens.
- C'est tout à fait vrai. J'ai seulement mentionné, qu'il n'est pas cohérent de l'information disponible à ce sujet. Ou de toute norme. Aussi viens de remarquer que c'est à dire de Chrome a des problèmes pour exécuter un fichier javascript qui vous a été envoyé avec Content-Type: text/javascript mais pas avec application/javascript. CSS est aussi un morceau de logiciel et pas conçu pour être lu par les utilisateurs, mais il est text/css.
InformationsquelleAutor Quentin
21

mime-types de départ avec x- ne sont pas standardisés. Dans le cas du javascript, il est un peu obsolète.
Supplémentaire de la deuxième extrait de code
```
<?Header('Content-Type: text/javascript');?>
```
nécessite short_open_tags à être activé. vous devriez éviter.
```
<?php Header('Content-Type: text/javascript');?>
```
Cependant, la complètement corriger mime-type pour le javascript est
```
application/javascript
```
http://www.iana.org/assignments/media-types/application/index.html
- Vieux la réponse, mais ne sais pas si c'est bon de commencer avec manches balises ouvertes jusqu'à ce que n'est pas recommandé (nous recommandons fortement que vous désactiver PHP-SOT en fait)
InformationsquelleAutor KingCrunch
8

Selon la RFC 4329 le bon type MIME pour le JavaScript doit être application/javascript. Cependant, les anciennes versions IE étranglement sur cette car ils attendent de text/javascript.
- Pour autant que je suis au courant, c'est à dire ne pas donner un singe est ce que le HTTP de type de contenu dit; seulement ce que le HTML type attribut dit (et dans le HTML 5 brouillons que l'attribut peut être omis pour le JavaScript).
- ahh... c'est ce qui me faisait mal. Merci!
InformationsquelleAutor Björn
3

Utiliser type="application/javascript"

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

http://www.w3.org/TR/html5/scripting-1.html#attr-script-type

Le type
attribut donne le langage de script ou de format de données. Si
l'attribut est présent, sa valeur doit être valide, type MIME. L'
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".

Utiliser "application/javascript", parce que "text/javascript" est obsolète:
RFC 4329: http://www.rfc-editor.org/rfc/rfc4329.txt
1. Déployé Script Types de Médias et de la Compatibilité
  
  Divers non types de supports ont été utilisés dans un ad-hoc
  la mode de l'étiquette et de l'échange des programmes écrits en ECMAScript et
  Le JavaScript. Elles comprennent:
  
  +-----------------------------------------------------+
  | text/javascript | text/ecmascript |
  | texte/javascript1.0 | texte/javascript1.1 |
  | texte/javascript1.2 | texte/javascript1.3 |
  | texte/javascript1.4 | texte/javascript1.5 |
  | texte/jscript | texte/livescript |
  | text/x-javascript | text/x-ecmascript |
  | application/x-javascript | application/x-ecmascript |
  | application/javascript | application/ecmascript |
  +-----------------------------------------------------+
Utilisation du "texte" de niveau supérieur de type pour ce genre de contenu est connu pour être
problématique. Ce document définit ainsi text/javascript et texte/

ecmascript, mais des marques comme "obsolète". Expérimentale et

non types de médias, 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 le présent document, sont communs
utilisation et doit être utilisé à la place.

Ce document définit équivalent exigences en matière de traitement de l'

les types text/javascript, text/ecmascript, et de l'application/javascript.

L'utilisation et le soutien pour les médias de type application/ecmascript est

beaucoup moins répandue que les autres types de médias défini dans l'

le présent document. À l'aide de qui à son avantage, ce document définit

plus strictes règles de traitement pour ce type de favoriser la plus interopérable

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

InformationsquelleAutor juFo

Vous devez vous connecter pour publier un commentaire.