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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
