[squid-users] caching js/css references with parameters, possible squid bug

[Amos Jeffries]

On 20/03/2016 12:50 a.m., Waitman Gobble wrote:
> 
> 
> On 2016-03-18 01:00, Amos Jeffries wrote:
> 
>> On 18/03/2016 3:46 a.m., Waitman Gobble wrote:
>>
>>> When a script reference on an HTML page includes a parameter, the script
>>> does not appear to be cached when using squid in accel mode (https).
>>>
>>> For example,
>>> <script type='text/javascript'
>>> src='/wp-includes/js/jquery/jquery.js?ver=1.1.13'></script>
>>>
>>> jquery.js does not appear to be cached in that case, each page request
>>> hits the originserver with a request for jquery.js. (also seems browser
>>> does not cache, either).
>>
>> How are you determining that?
>>
>> Dynamic content (as signalled by the '?query-string') is expected to
>> revalidate on each use unless that origin has sent explicit cacheability
>> headers. In HTTP/1.1 contact with the origin server is not always a full
>> fetch.
> 
> 
> I was watching HTTP logs on origin server, every page request was also
> creating request for css, js, etc.
> 
> waitman.net - [19/Mar/2016:03:47:04 -0700] "GET
> /wp-content/themes/mh-magazine-lite/style.css?ver=2.1.2 HTTP/1.1" 200
> 38550 "-"
> 
> After removing ?ver from html page, there was initial request:
> 
> waitman.net - [19/Mar/2016:03:50:15 -0700] "GET
> /wp-content/themes/mh-magazine-lite/style.css HTTP/1.1" 200 38550 "-"
> 
> but after that it was served from cache and no more hits on origin.
> 
> Perhaps it was not doing a "full request", but I was looking at the
> content length in the logs, 38550
> 

What you describe appears to be the visible behaviour when the URL
contains a "?" and the reply lacks explicit expiry information.
The requirement that Squid is obeying and its reason for existence is
documented in <http://tools.ietf.org/html/rfc2616#section-13.9> paragraph 2.

The current RFC 7230 document lifted that restriction, making it
OPTIONAL simply because the Internet has not broken too badly with very
few implementations (other than Squid) following that requirement.

Current Squid implement it in the form of the default "refresh_pattern
-i (/cgibin/|\?) 0 0% 0" rule - which is only used on replies lacking
Expires or Cache-Control headers. You can add a previous rule to handle
WP responses caching times if you like, or comment out that pattern if
you are certain that the situation documented by RFC 2616 is not going
to occur on *any* URL served by your Squid.

Amos