Quando si servono file JavaScript, è meglio usare application / javascript o application / x-javascript

95

L'intera domanda rientra nel titolo. E per aggiungere un po 'di contesto: non sto chiedendo quale sia il migliore in base a ciò che dicono le specifiche, ma piuttosto cosa funziona meglio dato il mix di browser implementato al giorno d'oggi.

Alcuni punti dati:

  • Google utilizza text/javascriptper il JS utilizzato nella sua home page.
  • Google utilizza text/javascriptsu Google Docs.
  • Google utilizza application/x-javascriptper fornire file JavaScript con il proprio servizio di librerie Ajax .
  • Yahoo utilizza application/x-javascriptper servire il proprio JS.
  • Yahoo utilizza application/x-javascriptper il JavaScript pubblicato sulla loro home page.
javascript  http  content-type 
— avernet
fonte
4
Divertente. Dai una terza alternativa nei tuoi esempi ... E secondo Tim, entrambi i grandi giocatori si sbagliano (riguardo agli standard), il che probabilmente significa solo che i browser sono tolleranti (nessuna grande novità qui) e potrebbe non avere importanza.
— PhiLho
1
possibile dupe: Javascript MIME Type
— Bergi

Risposte:

115
  • text/javascript è obsoleto
  • application/x-javascript era sperimentale mentre decideva di trasferirsi a ...
  • application/javascript è l'attuale tipo MIME ufficiale per JS

Detto questo, i browser spesso ignorano il messaggio content-typeinviato dal server e prestano molta attenzione typeall'attributo (e alcuni potrebbero non riconoscerlo application/javascript).

La mia raccomandazione:

  • Usa application / javascript sul server
  • Usa HTML 5 e ometti l' typeattributo dagli elementi dello script

NB: la specifica HTML contraddice lo standard MIME, e c'è un tentativo di cambiarla di nuovo in text/javascriptmodo che possa cambiare in futuro.

— Quentin
fonte
3
Questa domanda di qualche mese fa dice l'esatto contrario. Qualcuno si sbaglia :) "Kelly ha ragione, i browser tendono a fidarsi del tipo MIME inviato con le intestazioni di risposta sull'attributo type del tag script" stackoverflow.com/questions/189850/…
— Marco
6
Oh no! Le organizzazioni grandi, monolitiche e lente devono avere ragione! Le specifiche devono essere sbagliate! Narghh. Continuerò a fidarmi delle specifiche e della mia esperienza su grandi (lente) aziende, anche se una di loro mi ha impiegato.
— Quentin
1
Hmm, qualcuno ha dimenticato di dire a W3C che text / javascript è obsoleto. Sembra essere l' impostazione predefinita in HTML 5 . :: scratches head :: Sembra anche (se la mia lettura superficiale di questa sezione è corretta) che i programmi utente dovrebbero andare solo sull'attributo type, ignorando così il Content-typecomportamento sarebbe corretto.
— big_m
1
@ big_m - Questo perché molti browser non riconoscono, application/javascriptquindi specificarlo farà sì che ignorino lo script. I programmi utente non dovrebbero ignorare il Content-Type. L'attributo type dice loro cosa aspettarsi. Se non lo supportano, non dovrebbero preoccuparsi di richiederlo. Se il server dice che è qualcosa di diverso, dovrebbe continuare su quello piuttosto che su quello che dice l'HTML (almeno secondo HTTP, potresti guardare una specifica diversa, non hai fornito alcun collegamento).
— Quentin
1
@Quentin, mi riferivo alla sezione HTML 5 scriptsull'elemento, a cui mi sono collegato. La mia lettura di quella sezione è diversa da quella che descrivi; sembra dare molta importanza typeall'attributo e non fa menzione del controllo del Content-Type, tranne che per determinare la codifica dei caratteri. Sono d'accordo che sembra che sarebbe saggio per il programma utente verificare che il tipo di contenuto corrisponda a ciò che ci si aspetta, ma non ho trovato nulla nelle specifiche HTML che richieda o addirittura raccomandi di farlo.
— big_m
7

Se scegli di utilizzare application / javascript per js nelle tue pagine, IE7 e IE8 non eseguiranno il tuo script! Dai la colpa a Microsoft quanto vuoi, ma se vuoi che la maggior parte delle persone esegua le tue pagine usa text / javascript.

— Drew B
fonte
3
Quando dici che "applicazione / javascript" non funzionerà, intendi se è impostato come tipo di contenuto nella risposta HTTP o come attributo "tipo" di un tag script? La domanda originale era sul tipo di contenuto sulle risposte HTTP. Sulla base di altre risposte sembra che solo il valore dell'attributo "tipo" sui tag di script farà la differenza in entrambi i casi in IE.
— Jesse Hallett
7

Lo era language="javacript". Quindi è cambiato in type="text/javascript". Adesso lo è type="application/javacript". Ok, questo sta diventando stupido. Alcuni dei browser meno recenti non riconoscono il nuovo application/javascript, ma riconoscono comunque il vecchio text/javascript. Ho intenzione di continuare a usarlo, altrimenti sprecherò ore del mio tempo cercando di cambiare OGNI istanza di text/javascriptin application/javascript.
Ora un giorno potrebbe essere vero il contrario. Un giorno i browser più recenti potrebbero rifiutare la vecchia tecnica per essere strettamente conformi agli standard.
Ma fino a quando le persone che visualizzano il mio sito web iniziano a lamentarsi del fatto che "da quando ho aggiornato il mio browser, circa il 50% del tuo sito web è scomparso", non ho motivo di cambiare il codice nel mio sito web.

— Sandip Armal Patil
fonte
7

Ecco la risposta del 2020 a questa domanda.

text/javascriptè il tipo MIME JavaScript corretto per lo standard HTML , che afferma:

I server dovrebbero utilizzare text/javascriptper le risorse JavaScript. I server non devono utilizzare altri tipi MIME JavaScript per le risorse JavaScript e non devono utilizzare tipi MIME non JavaScript.

E inoltre :

[…] Il tipo MIME utilizzato per fare riferimento a JavaScript in questa specifica è text/javascript, poiché è il tipo più comunemente usato, nonostante sia un tipo ufficialmente obsoleto secondo RFC 4329.

Sono in corso lavori per riflettere questa realtà in un RFC a livello IETF: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Qualsiasi affermazione che " text/javascriptè quella obsoleta" lo dice sulla base della RFC 4329, che sia lo standard HTML che la bozza IETF sopra menzionata (cioè una prossima RFC) stanno correggendo esplicitamente.

— Mathias Bynens
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.