[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[Yuri Voinov]

-----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 at lists.squid-cache.org
> 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-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161024/553079da/attachment-0001.key>