We Keep Coding

Why not to create your own custom content-type

I'm using a web service(API) framework that does some magic behind the scene for different content-types requests.
I want to take advantage of that by creating responses like application/verbose+json but the actual content will still be application/json.
I've implemented it, tested it from a jquery.ajax call in chrome and it all works.
Is there a reason this is wrong or might not work in production/long run?
Not relevant to the question but just in case you're wondering about what it's written in:
- server side: tastypie(python on django)
- client side: javascript/coffeescript on backbone

Internet Media Types (what you call content types) form a global space of names. If you use a "custom" name, you risk that there'll be future name collisions.
If you really think your custom name is needed, please consider registering it, see https://www.rfc-editor.org/rfc/rfc6838 (there are also vendor and personal spaces).

Custom content-type hasn't raised any issue until now in production, so i'll solve this issue by saying it's safe.

Embedding Javascript (file): what means "filename.js?v=2.0.4"? [duplicate]

When I saw many sites' source code, parameters were passed to the linking file (CSS/JavaScript).
In the Stack Overflow source, I got
<script type="text/javascript" src="http://sstatic.net/js/master.js?v=55c7eccb8e19"></script>
Why is master.js?v=55c7eccb8e19 used?
I am sure that JavaScript/CSS files can't get the parameters.
What is the reason?

It is usually done to prevent caching.
Let's say you deploy version 2 of your new application and you want to cause the clients to refresh their CSS, you could add this extra parameter to indicate that it should re-request it from the server. Of course there are other approaches as well, but this is pretty simple.

As the others have said, it's probably an attempt to control caching, although I think it's best to do so by changing the actual resource name (foo.v2.js, not foo.js?v=2) rather than a version in the query string. (That doesn't mean you have to rename files, there are better ways of mapping that URL to the underlying file.) This article, though four years old and therefore ancient in the web world, is still a quite useful discussion. In it, the author claims that you don't want to use query strings for versions because:
...According the letter of the HTTP caching specification, user agents should never cache URLs with query strings. While Internet Explorer and Firefox ignore this, Opera and Safari don’t...
That statement may not be quite correct, because what the spec actually says is
...since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time...
(That emphasis at the end is mine.) So using a version in the query string may be fine as long as you're also including explicit caching headers. Provided browsers implement the above correctly. And proxies do. You see why I think you're better off with versions in the actual resource locator, rather than query parameters (which [again] doesn't mean you have to constantly rename files; see the article linked above for more). You know browsers, proxies, etc. along the way are going to fetch the updated resource if you change its name, which means you can give the previous "name" a never-ending cache time to maximize the benefit of intermediate caches.
Regarding:
I am sure that Js/CSS files can't get the parameters.
Just because the result coming back is a JavaScript or CSS resource, it doesn't mean that it's a literal file on the server's file system. The server could well be doing processing based on the query string parameters and generating a customized JavaScript or CSS response. There's no reason I can't configure my server to route all .js files to (say) a PHP handler that looks at the query string and returns something customized to match the fields given. Thus, foo.js?v=2 may well be different from foo.js?v=1 if I've set up my server to do so.

That's to avoid the browser from caching the file. The appending version name has no effect on the JavaScript file, but to the browser's caching engine it looks like a unique file now.
For example, if you had scripts.js and the browser visits the page, they download and cache (store) that file to make the next page visit faster. However, if you make a change the browser may not recognize it until the cache has expired. However, scripts.js?v2 now makes the browser force a re-fetch because the "name's changed" (even though it hasn't, just the contents have).

A server-side script generating the CSS or JavaScript code could make use of them, but it is probably just being used to change the URI when the the content of the file changes so that old, cached versions won't cause problems.

<script type="text/javascript">
// front end cache bust
var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];
for (i=0;i<cacheBust.length;i++){
var el = document.createElement('script');
el.src = cacheBust[i]+"?v=" + Math.random();
document.getElementsByTagName('head')[0].appendChild(el);
}
</script>

This is to force the browser to re-cache the .js file if there has been any update.
You see, when you update your JS on a site, some browsers may have cached the old version (to improve performace). Sicne you want them to use your new one, you can append something in the query-field of the name, and voíla! The browser re-fetches the file!
This applies to all files sent from the server btw.

Since javascript and css files are cached by the client browser, so we append some numeric values against their names in order to provide the non-cached version of the file

"I am sure that JavaScript /CSS files can't get the parameters"
function getQueryParams(qs) {
qs = qs.split("+").join(" ");
var params = {},
tokens, re = /[?&]?([^=]+)=([^&]*)/g;
while (tokens = re.exec(qs)) {
params[decodeURIComponent(tokens[1])] = decodeURIComponent(tokens[2]);
}
return params;
}

This is referred to as Cache Busting.
The browser will cache the file, including the querystring. Next time the querystring is updated the browser will be forced to download the new version of the file.
There are various types of cache-busting, for example:
Static
Date/Time
Software Version
Hashed-Content
I've wrote an article on cache busting previously which you may find useful:
http://curtistimson.co.uk/front-end-dev/what-is-cache-busting/

What does the "?" sign mean in a request for a static JS file?

I've seen that a lot and I just don't know what it means. This, for example:
<script src="http://server.com/file.js?y=2345678" type="text/javascript"></script>
If it is in deed possible to 'catch' the value of 'y' in the javascript file, how would that be?
Thank you.
PS. I know what mod_rewrite is and that is not the answer, just in case :)

This is to force the browser not to cache the file, by making it believe that it is a dynamic file with get parameter rather than a static one.

This is often used to facilitate caching of the JS file. You set a far-future Expires header which means the browser may cache it for a very long time. If you change something in the file you also update the number in the querystring, which will make the browser refetch the file. This works because caching is for unique filenames and the querystring is part of the filename (as far as the browser is concerned).
A similar approach to this is to use rewrite rules in the web server to have some part of the file name which it doesnät care about. Here's a Nginx rule to show what I mean:
rewrite ^/style\..*\.css$ /style.css;
I use this rule to have filenames like style.42750cad6.css, which always points to the file style.css. The text in the middle is changed whenever I change style.css. The difference between the first approach is that this does not use the querystring so the caching will work in more browsers.

ok the way i see it in two ways.
it can be used to load js without caching
for every request to the server, the server might log information(if logging is enabled), if i am using it for analytics i can therefore use a different parameter for locations and from the log i can analyse and get required details.

What is the ? in html links tags?

If you have a link or script tag, say to a css or js document, and you have something like ?1 in the url, what is that? Example:
<script src="home.js?1" type="text/javascript"></script>
Just a basic question...

This is for caching purposes. For example, the next time that script gets updated the developer can add a ?2 at the end and the browser will fetch the new version not the cached.

It denotes the beginning of the Query String, used to pass values around, or commonly just to create a randomized portion of the URL to avoid cached results.
In your example, the user is likely tacking on a new value to constantly create a unique URL that ultimately goes to the same place, and requests the same thing.

The part after the question mark is called the query string.
The query string is ignored when the server maps the request to a file on disk, but it can be used by server-side scripts.
In this case, the query string is being used to avoid caching.
When the script is changed, the query string can be changed to ?2 and it will not use the previous version from the cache.

It just keeps it from caching. Normally the browser caches those files, so adding a ? plus a random number will make the browser see it as a different url, thus reloading the file. Its not really necessary since most browsers will reload cached files with Ctrl+R.

What follows the ? is the query string. It is used to pass parameters to the src file and sometimes to prevent caching by adding a random number to the file string to force the browser to fetch from the server.

The '?' separates the resource identifier from the query parameters of the URL. I'm not sure if I'm naming them correctly. Often a CMS will add ?1 to the URL for a CSS or other page to avoid browser cacheing for the elements. Each time you edit the CSS, the number will get bumped to the next value so the browser is sure to reload the CSS or script or whatever.

? separates the URL from the parameters. Parameters would follow the ?. After the ? you should use & separate multiple parmaeters. e.g. www.google.com?q=URL&language=en

What are best practices for preventing stale CSS and JavaScript

I'm researching this for a project and I'm wondering what other people are doing to prevent stale CSS and JavaScript files from being served with each new release. I don't want to append a timestamp or something similar which may prevent caching on every request.
I'm working with the Spring 2.5 MVC framework and I'm already using the google api's to serve prototype and scriptaculous. I'm also considering using Amazon S3 and the new Cloudfront offering to minimize network latency.

I add a parameter to the request with the revision number, something like:
<script type="text/javascript" src="/path/to/script.js?ver=456"></script>
The 'ver' parameter is updated automatically with each build (read from file, which the build updates). This makes sure the scripts are cached only for the current revision.

Like #eran-galperin, I use a parameter in the reference to the JS file, but I include a server-generated reference to the file's "last modified" date. #stein-g-strindhaug suggests this approach. It would look something like this:
<script type="text/javascript" src="/path/to/script.js?1347486578"></script>
The server ignores the parameter for the static file and the client may cache the script until the date code changes. If (and only if) you modify the JS file on the server, the date code will change automatically.
For instance, in PHP, my script to create this code looks like this:
function cachePreventCode($filename) {
if (!file_exists($filename))
return "";
$mtime = filemtime($filename);
return $mtime;
}
So then when your PHP file includes a reference to a CSS file, it might look like this:
<link rel="stylesheet" type="text/css" href="main.css?<?= cachePreventCode("main.css") ?>" />
... which will create ...
<link rel="stylesheet" type="text/css" href="main.css?1347489244" />

With regards to cached files, I have yet to run into any issues of bugs related to stale cached files by using the querystring method.
However, with regards to performance, and echoing Todd B's mention of revving by filename, please check out Steve Souders' work for more on the topic:
"Squid, a popular proxy, doesn’t cache resources with a querystring. This hurts performance when multiple users behind a proxy cache request the same file - rather than using the cached version everybody would have to send a request to the origin server."
"Proxy administrators can change the configuration to support caching resources with a querystring, when the caching headers indicate that is appropriate. But the default configuration is what web developers should expect to encounter most frequently."
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

Use a conditional get request with an If-Modified-Since header

This is actually a very hard issue, and something that you can spend a while engineering the correct solution for.
I would recommend publishing your files using a timestamp and/or version built into the url, so instead of:
/media/js/my.js you end up with:
/media/js/v12/my.js or something similar.
You can automate the versioning/timestamping with any tool.
This has the added benefit of NOT breaking the site as you roll out new versions, and lets you do real side-by-side testing (unlike a rewrite rule that just strips the version and sends back the newest file).
One thing to watch out for with JS or CSS is when you include dependent urls inside of them (background images, etc) you need to make sure the JS/CSS timestamp/version changes if a resource inside does (as well as rewrite them, but that is possible with a very simple regex and a resource manifest).
No matter what you do make sure not to toss a ?vblah on the end, as you are basically throwing caching out the window when you do that (which is unfortunate, as it is by far the easiest way to handle this)

If you get the "modified time" of the file as a timestamp it will be cached until the file is modified. Just use a helper function (or whatever it is called in other frameworks) to add script/css/image tags that get the timestamp from the file. On a unix like system (wich most survers are) you could simply touch the files to force the modified time to change if necessary.
Ruby on Rails uses this strategy in production mode (by default I beleave), and uses a normal timestamp in development mode (to be really sure something isn't cached).

If you use MAVEN, you can use this, ADD on you pom.xml:
<properties>
<maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
<timestamp>${maven.build.timestamp}</timestamp>
</properties>
With this you can acess ${timestamp} in your view.
Like this sample:
<script type="text/javascript" src="/js/myScript.js?t=${timestamp}"></script>

Based on Todd Berman's answer of incorporating a revision number into the URL (but not as a query string), a perhaps slightly more convenient approach would be to have the server transform the versioned URL into a canonical form. This could be done with symlinks, e.g.:
/media/js/v12/my.js => /media/js/my.js
or you could set up server-side URL rewrites to always transform paths of the form /media/js/v*/my.js to, say, /media/js/my.js.