-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 24.10.2016 22:05, Garri Djavadyan пишет: > 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/google-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. Of course, one does not violate the standards. Just a little do not follow the recommendations. It also does not interfere with critical transactions, right? Just prevent caching. But this is no problem here - you can download file? That's enough. Isn't it? Corporation of Good allows itself not to follow the recommendations. What is permitted to Jupiter - the bull is not allowed, is not it? They do all by rule - "Because we can". We are, instead, must follows "Because we can't". Nothing personal, no trolling. Just a note. > > [1] https://tools.ietf.org/html/rfc7231#section-4.3.2 > > Garri > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users - -- Cats - delicious. You just do not know how to cook them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYDjSeAAoJENNXIZxhPexGAHAIAIDM3QyTLdMbK+HTz8o8zBnH eKbnCBdkiDUalojgVlkWwW6llp78lFdJWf8ilzKpq9WE83g8fiesUMz5qQzShtqg OFD9NT25w793L0F7Ne7b4haPqSh05RgIsPvri0PWSy1WRLBV1l+nHAKHzsTLoZ6w MmtoQycP86p8z+FuuOg1mkmjlgUAlfeG0jWWQkwxfYcn0vxi2vM1nLc00xCxJi4U iX3dbzWPuPDlljO+wm6ZKaOiQCdjTb8pk5AmFaFH/hhOIflffhPZdMBVikWAhaCp 1p8YTlUJvKj2nmP9SVkrFSFP5/AmAy0AZn+Cbg79+4lWRG2+KwepCAoO7EMbS4Q= =hPcm -----END PGP SIGNATURE-----
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
