2

I noticed that there's a whole bunch of different content types, some of them seem redundant.

Wouldn't a js file that's served as text/plain work just as well as if it was served with text/javasctipt?

I plan on making a page that's serve-able as a ajax/json/jsonp file (with or without a callback) or as a plain page that users on a dumb phone or with no js can view as a text file.

Is there any disadvantage as always displaying a page as text/plain ? Will it ever be a problem if I'm getting it as a script? What about the inverse?

qwertymk
  • 32,454
  • 27
  • 117
  • 182
  • take a look here: http://stackoverflow.com/questions/4101394/javascript-mime-type , theres detailed explanation about javascript mime type – poncha Mar 28 '12 at 20:36

3 Answers3

3

Wouldn't a js file that's served as text/plain work just as well as if it was served with text/javasctipt?

Only if it would be executed as JavaScript regardless. If text/plain meant something to the client distinct from text/javascript then the effects would (could) be different. Fortunately it usually doesn't when the browser loads it due to a <script> tag.

Ignacio Vazquez-Abrams
  • 740,318
  • 145
  • 1,296
  • 1,325
2

An advantage of using text/javascript is that it will allow you to include non '.js' postfixed files and they will be rendered as javascript.

For instance, I usually have a global.config file - which is a javascript written configuration object. I can use the postfix '.config' which is very helpful visually - but still use have it render as javascript.

kajacx
  • 11,343
  • 5
  • 38
  • 66
msponagle
  • 330
  • 1
  • 11
0

When a Javascript is inserted dynamically, the navigator will give you correct events and states of reception (readyState with Intrenet Explorer, onload with FireFox) if the content is type "text/javascript". It can make wrong or lazy response if it's "text/plain".

Skrol29
  • 5,192
  • 1
  • 19
  • 25