3

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
  • 34,200
  • 28
  • 121
  • 184
  • 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
  • 776,304
  • 153
  • 1,341
  • 1,358
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
  • 12,361
  • 5
  • 43
  • 70
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,402
  • 1
  • 20
  • 25