[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[Garri Djavadyan]

On Mon, 2016-10-24 at 21:05 +0500, Garri Djavadyan wrote:
> On 2016-10-24 19:40, Garri Djavadyan wrote:
> > 
> > So, the big G sends 304 only to HEAD requests, although it is a
> > violation [1], AIUI:
> > 
> > curl --head -H 'If-Modified-Since: Thu, 20 Oct 2016 08:29:09 GMT'
> > -H
> > 'If-None-Match: "101395"' http://dl.google.com/linux/direct/google-
> > chro
> > me-stable_current_amd64.deb
> > HTTP/1.1 304 Not Modified
> > ETag: "101395"
> > Server: downloads
> > Vary: *
> > X-Content-Type-Options: nosniff
> > X-Frame-Options: SAMEORIGIN
> > X-Xss-Protection: 1; mode=block
> > Date: Mon, 24 Oct 2016 14:36:32 GMT
> > Connection: keep-alive
> > 
> > ---
> > 
> > $ curl --verbose -H 'If-Modified-Since: Thu, 20 Oct 2016 08:29:09
> > GMT'
> > -H 'If-None-Match: "101395"' http://dl.google.com/linux/direct/goog
> > le-c
> > hrome-stable_current_amd64.deb > /dev/null
> > > 
> > > GET /linux/direct/google-chrome-stable_current_amd64.deb HTTP/1.1
> > > Host: dl.google.com
> > > User-Agent: curl/7.50.3
> > > Accept: */*
> > > If-Modified-Since: Thu, 20 Oct 2016 08:29:09 GMT
> > > If-None-Match: "101395"
> > > 
> > < HTTP/1.1 200 OK
> > < Accept-Ranges: bytes
> > < Content-Type: application/x-debian-package
> > < ETag: "101395"
> > < Last-Modified: Thu, 20 Oct 2016 08:29:09 GMT
> > < Server: downloads
> > < Vary: *
> > < X-Content-Type-Options: nosniff
> > < X-Frame-Options: SAMEORIGIN
> > < X-Xss-Protection: 1; mode=block
> > < Date: Mon, 24 Oct 2016 14:38:19 GMT
> > < Content-Length: 45532350
> > < Connection: keep-alive
> > 
> > [1] https://tools.ietf.org/html/rfc7234#section-4.3.5
> 
> Actually I mixed SHOULD agains MUST. The RFC 7231, section 4.3.2
> states 
> [1]:
> ...
> The server SHOULD send the same header fields in response to a HEAD 
> request as it would have sent if
> the request had been a GET, except that the payload header fields 
> (Section 3.3) MAY be omitted.
> ...
> 
> So, big G does not follow the recommendation, but does not violate
> the 
> standard.
> 
> [1] https://tools.ietf.org/html/rfc7231#section-4.3.2
> 
> Garri

I've overlooked that the statement applies to header _fields_, not to
reply code. The full paragraph states:

   The HEAD method is identical to GET except that the server MUST NOT
   send a message body in the response (i.e., the response terminates
   at the end of the header section).  The server SHOULD send the same
   header fields in response to a HEAD request as it would have sent if
   the request had been a GET, except that the payload header fields
   (Section 3.3) MAY be omitted.  This method can be used for obtaining
   metadata about the selected representation without transferring the
   representation data and is often used for testing hypertext links  
   for validity, accessibility, and recent modification.

Nevertheless, the last sentence in the above excerpt use word 'can',
same for the following excerpt from section 4.3.5 [1]:

   A response to the HEAD method is identical to what an equivalent
   request made with a GET would have been, except it lacks a body.
   This property of HEAD responses can be used to invalidate or update
   a cached GET response if the more efficient conditional GET request
   mechanism is not available (due to no validators being present in  
   the stored response) or if transmission of the representation body  
   is not desired even if it has changed.

So, HEAD request _can_ be used as a reliable source for object
revalidation. How the 'can' should it be interpreted? RFC2119 [2] does
not specifies that.


AIUI, that exact case leaves two choices:

* Implement something like 'revalidate_using_head [[!]acl]
* Contact Google and inform about the behavior

The former is RFC-compliant way to solve that particular case, but
requires costly development efforts and may be useless after some time.
The latter may break HEAD revalidation also, but gives hopes that the
GET conditionals may be fixed.

[1] https://tools.ietf.org/html/rfc7234#section-4.3.5
[2] https://tools.ietf.org/html/rfc2119