En théorie, selon RFC 4329 , application/javascript.
La raison pour laquelle il est censé être applicationn'a rien à voir avec le fait que le type soit lisible ou exécutable. C'est parce qu'il existe des mécanismes de détermination de jeu de caractères personnalisés définis par le langage / type lui-même, plutôt que simplement par le charsetparamètre générique . Un sous-type de textdoit pouvoir être transcodé par un proxy vers un autre jeu de caractères, en modifiant le paramètre charset. Ce n'est pas le cas de JavaScript car:
une. le RFC dit que les agents utilisateurs devraient faire un reniflage de nomenclature sur le script pour déterminer le type (je ne suis pas sûr que les navigateurs le fassent réellement);
b. les navigateurs utilisent d'autres informations - le codage de la page d'inclusion et dans certains navigateurs l' script charsetattribut - pour déterminer le jeu de caractères. Ainsi, tout proxy qui tenterait de transcoder la ressource briserait ses utilisateurs. (Bien sûr, en réalité, personne n'utilise jamais de proxy de transcodage de toute façon, mais c'était l'intention.)
Par conséquent, les octets exacts du fichier doivent être conservés exactement , ce qui en fait un applicationtype binaire et non techniquement basé sur des caractères text.
Pour la même raison, application/xmlest officiellement préféré à text/xml: XML a ses propres mécanismes de signalisation de jeu de caractères dans la bande. Et tout le monde ignore également le applicationXML.
text/javascriptet text/xmlpeut ne pas être la bonne chose officielle, mais il y a ce que tout le monde utilise aujourd'hui pour des raisons de compatibilité, et les raisons pour lesquelles ils ne sont pas la bonne chose sont pratiquement sans importance.