[squid-dev] Fix If-None-Match processing and related bug 4169
Amos Jeffries
squid3 at treenet.co.nz
Tue Nov 29 21:23:25 UTC 2016
On 30/11/2016 1:47 a.m., Garri Djavadyan wrote:
> On Tue, 2016-11-29 at 14:51 +0500, Garri Djavadyan wrote:
>> Hello,
>>
>> Please review the attached patch prepared for r14958, it fixes the
>> If-
>> None-Match processing (incorrect logging [1]) and the bug [2] report
>> 4169 depending on the incorrect (IMO) behavior.
>>
>> An If-None-Match request for a non-matched (ETag) but cached object
>> should be processed as normal HIT.
>>
>> [1] http://lists.squid-cache.org/pipermail/squid-users/2016-November/
>> 01
>> 3483.html
>> [2] http://bugs.squid-cache.org/show_bug.cgi?id=4169
>>
>> Thanks.
>>
>> Garri
>
> I've attached second version of the patch. In the first version I
> removed strings (not related to the fix) which mark a request as non-
> IMS, because I thought the same request could not
> enter processConditional twice and the removed actions are redundant.
> Now I'm not sure about it.
>
The logic looks a bit funky and that is probably a side effect of
RFC2616 confusion.
Checking this whole processConditional() sequence for compliance with
RFC 7232 and 7234 the rest of the logic seems to be fine except this case:
<https://tools.ietf.org/html/rfc7234#section-4.3.2>
"
If the field-value is "*", or if the
field-value is a list of entity-tags and at least one of them matches
[ e->hasIfNoneMatchEtag(r) == false --> !N == true ]
the entity-tag of the selected stored response, a cache recipient
SHOULD generate a 304 (Not Modified) response (using the metadata of
the selected stored response) instead of sending that stored
response.
"
so this is supposed to be a 304 response which is a HIT, perhapse with a
new 'INM' LogTag flag set to true.
Amos
More information about the squid-dev
mailing list