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 _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
