#14348 closed bug (notabug)
Make jQuery Migrate CDN cacheable (SSL) by adding "cache-control: public"
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | web | Version: | 1.10.2 |
Keywords: | Cc: | gnarf | |
Blocked by: | Blocking: |
Description
The following URL:
https://code.jquery.com/jquery-migrate-1.2.1.min.js
returns the following response header:
Cache-Control: max-age=315360000
Please change it to:
Cache-Control: public, max-age=315360000
in order to allow proxies and some web browsers to cache the resource.
Thank you.
For comparison, any other CDN properly configured will add "public" to the "cache-control" header, here is an example:
https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
Addressing this bug will solve caching issues with proxies, some client browsers, will reduce CDN costs, solve worldwide bandwidth overload issues, reduce climatic impact and global warming caused by jQuery, will prevent child death, suffering kitties, ...
Change History (10)
comment:1 Changed 10 years ago by
Cc: | gnarf added |
---|---|
Component: | unfiled → web |
Priority: | undecided → low |
Status: | new → open |
comment:2 follow-up: 3 Changed 9 years ago by
Resolution: | → notabug |
---|---|
Status: | open → closed |
Moved to our infrastructure issues list.
comment:3 follow-up: 7 Changed 9 years ago by
Replying to dmethvin:
Moved to our infrastructure issues list.
Woaww..... How to silently close a bug that is still not fixed more than 6 months after its report.
Replying to dmethvin:
Moved to our infrastructure issues list.
Can we have a link to this so called "infrastructure issues list"?
It's been 6 months that I actively recommend against using the jQuery CDN because of this problem, and now I will start to simply tell the true about your way of handling bugs when they are kindly reported to you. Especially as changing a simple Cache-Control header is something that should take no more than 10 seconds for any CDN configuration.
jQuery might be popular, but you suck.
comment:4 follow-up: 5 Changed 9 years ago by
How to silently close a bug that is still not fixed more than 6 months after its report.
Sometimes that happens when a report is misfiled. Sorry I didn't catch it earlier and put it in the right place.
Can we have a link to this so called "infrastructure issues list"?
Nope since it sometimes involves internal information and servers.
jQuery might be popular, but you suck.
Despite your negative encouragement, I'll try to keep this moving along.
comment:5 Changed 9 years ago by
Replying to dmethvin:
Can we have a link to this so called "infrastructure issues list"?
Nope since it sometimes involves internal information and servers.
So how can I know if the bug was fixed or not (rather than checking the response header myself every once in a while)?
Perhaps you could post an update here whenever it's fixed? Or just simply leave this bug open and close it only when it's fixed...
Thank you.
comment:6 follow-up: 8 Changed 9 years ago by
https://code.jquery.com/jquery-migrate-1.2.1.min.js
Now serves:
Cache-Control: public Cache-Control: max-age= 315360000
comment:7 Changed 9 years ago by
Replying to anonymous:
Woaww..... How to silently close a bug that is still not fixed more than 6 months after its report.
AKA - How to report the bug where the person who fixes it actually notices.
Replying to anonymous:
jQuery might be popular, but you suck.
Perhaps I do - Sorry I missed the cc on the core bug tracker 6 months ago, this would have been handled much sooner.
comment:8 Changed 9 years ago by
Replying to gnarf:
https://code.jquery.com/jquery-migrate-1.2.1.min.js
Now serves:
Cache-Control: public Cache-Control: max-age= 315360000
Thank you, finally! But isn't the second header overriding the first one?
comment:10 Changed 9 years ago by
Replying to dmethvin:
Google will tell you.
Very well, let's see what the specifications say...
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
In other words, please combine those two lines into one, as this is the preferred method according to the specs linked above.
Thank you.
Sounds reasonable. CC'ing corey