Kiedy używać JavaScript MIME typu application / javascript zamiast text / javascript?


157

Bazując na pytaniu, kod jQuery nie działa w IE , text/javascriptjest używany w dokumentach HTML, więc Internet Explorer może go zrozumieć.

Ale zastanawiam się, kiedy używałbyś application/javascript, a co ważniejsze, dlaczego miałbyś go używać zamiast text/javascript?


możliwe oszustwo / wyjaśnienie: stackoverflow.com/questions/876561/ ...
Benn



Odpowiedzi:


243

Teoretycznie, według specyfikacji RFC 4329 , application/javascript.

Powód, dla którego ma to być, applicationnie ma nic wspólnego z tym, czy typ jest czytelny, czy wykonywalny. Dzieje się tak, ponieważ istnieją niestandardowe mechanizmy określania zestawu znaków określone przez sam język / typ, a nie tylko przez ogólny charsetparametr. Podtyp textpowinien mieć możliwość transkodowania przez proxy na inny zestaw znaków, zmieniając parametr zestawu znaków. Nie dotyczy to JavaScript, ponieważ:

za. RFC mówi, że agenci użytkownika powinni węszyć BOM w skrypcie, aby określić typ (nie jestem pewien, czy jakakolwiek przeglądarka faktycznie to robi);

b. przeglądarki używają innych informacji - łącznie z kodowaniem strony, aw niektórych przeglądarkach script charsetatrybutem - do określenia zestawu znaków. Zatem każdy serwer proxy, który próbowałby transkodować zasób, złamałby jego użytkowników. (Oczywiście w rzeczywistości nikt i tak nigdy nie używa transkodujących serwerów proxy, ale taki był zamiar).

Dlatego dokładne bajty pliku muszą być dokładnie zachowane , co czyni go applicationtypem binarnym, a nie technicznie opartym na znakach text.

Z tego samego powodu application/xmljest oficjalnie preferowany w stosunku do text/xml: XML ma własne mechanizmy sygnalizacji zestawu znaków w paśmie. Wszyscy ignorują też applicationXML.

text/javascripti text/xmlmoże nie być oficjalną właściwą rzeczą, ale jest to, czego wszyscy używają dzisiaj ze względu na kompatybilność, a powody, dla których nie są one właściwe, są praktycznie całkowicie nieważne.


4
Najbardziej „kompatybilne” rozwiązanie polega na tym, aby w ogóle nie uwzględniać w odpowiedzi żadnego typu zawartości. RFC stwierdza, że ​​bez wyraźnego typu treści odbiorca zinterpretowałby ją „według kontekstu”, co jest zawsze poprawnym zachowaniem dla wszystkich przeglądarek, począwszy od pierwszych przeglądarek
Pacerier

Uważaj, application/javascripta IE działa w trybie zgodności z IE=8. Wygląda na to, że skrypty wbudowane nie są odpowiednio oceniane. text/javascriptdziała dobrze tam.
Joscha

2
@Pacerier - wiem, że ten komentarz ma 5 lat, ale ze względów bezpieczeństwa często najlepiej jest uwzględnić typy MIME, szczególnie w przypadku witryn typu forum. Zinterpretowanie typu przez odbiorcę pozostawia otwarte na atak, przesyłając złośliwy plik javascript jako obraz, a następnie prosząc przeglądarkę o zinterpretowanie i uruchomienie tego skryptu. Lepiej jest, aby serwer zwracał typy MIME dla wszystkich odpowiedzi i używał nagłówka, X-Content-Type-Options: nosniffaby uniemożliwić przeglądarce interpretację typu.
sammy_winter,

@sammy_winter Widzę takie ostrzeżenia wszędzie i za każdym razem się kulę. Gdybym zezwolił użytkownikom na przesyłanie treści, prawdopodobnie przeprowadziłbym więcej weryfikacji niż „o tak, nazwa wyrażenia regularnego dopasowana do pliku png, mogę temu ufać”, prawda? Jeśli niepoprawny nagłówek staje się „kwestią bezpieczeństwa”, problem może być głębszy, nie sądzisz? To jest to samo, co w przypadku ukrywania Server: nginxlub czegokolwiek, co wysyła nginx. Jakby ktoś, kto jest w stanie znaleźć dziurę, potrzebuje wyraźnego nagłówka, aby wiedzieć, jaki serwer uruchamiasz ...
Sahsahae

17

Problem z typem MIME w Javascript polega na tym, że od lat nie ma standardu. Teraz mamy application / javascript jako oficjalny typ MIME.

Ale w rzeczywistości typ MIME nie ma żadnego znaczenia, ponieważ przeglądarka może sam określić typ. Dlatego specyfikacje HTML5 stanowią, że plik type="text/javascript"nie jest już wymagany.


5

applicationponieważ .js-Pliki nie są czymś, co użytkownik chce przeczytać, ale czymś, co powinno zostać wykonane.


To oficjalna odpowiedź, ale IE się dławi.
Benn

20
@Benn: Może dlatego, że użytkownicy IE muszą czytać wszystkie pliki JS, ponieważ nie działają poprawnie? Przynajmniej jest to uczciwe przez Microsoft;)
thejh

Kocham swój komentarz, ale niestety ludzie, którzy nie potrafią czytać javascript nadal korzystać z IE, więc musimy sobie z tym poradzić :(.
Mark Baijens

1
Nie myślę, że chcesz to przeczytać, ma coś wspólnego z tym, dlaczego. Ma to związek ze sposobem transkodowania danych - a raczej, czy może tak być.
Zenexer

technicznie rzecz biorąc, HTML i CSS są również „wykonywane” (parsowane) przez przeglądarkę w celu wygenerowania wyniku kodu jako treści wizualnej i nie są przeznaczone dla użytkownika do „czytania” go, więc ta odpowiedź nie ma większego sensu. Wydaje mi się, że istnieje duże zamieszanie co do tego, co to jest „tekst”, a co „aplikacja”. Gdybym mógł zagłosować w tej sprawie, powiedziałbym, że IETF powinien rozważyć zawartość „tekstu” jako texti binaryalbo jakoapplication

1

application / javascript jest prawidłowym typem do użycia, ale ponieważ nie jest obsługiwany przez IE6-8, utkniesz z tekstem / javascript. Jeśli nie zależy Ci na poprawności (z wyłączeniem HTML5), po prostu nie określaj typu.


Skąd to masz? Jestem prawie pewien, że jest obsługiwany. A przynajmniej zostanie zignorowany.
Zenexer

@Zenexer przeczytał swoją odpowiedź na inne pytanie . Pozornie kompatybilność z IE oznacza nie application/javascript.
Camilo Martin,

@CamiloMartin Używam go dobrze z IE do 6 przez cały czas. Po prostu domyślnie obsługują JavaScript.
Zenexer

@Zenexer Hm, dziwne. Zastanawiam się, o co chodziło w innych pytaniach i odpowiedziach.
Camilo Martin

@Zenexer Minęło trochę czasu, odkąd musiałem sobie z tym poradzić, ale oto kilka innych kont powodujących problemy z IE6-8. Nie do końca jestem pewien, dlaczego wydaje się to mieć znaczenie tylko czasami, ale z mojego doświadczenia wynika, że ​​powoduje problemy.
Radu
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.