On 22/01/20 1:08 am, Kuznetsov Sergei wrote: > If I get you right, is this a problem with the web server. > Yes, exactly so. > I tried to explain to them with about the same logic, but they could not > reproduce the error and accordingly do not recognize the existence of > the problem. To reproduce, just deliver a valid If-None-Match header to their server. Request: GET /js/jquery-1.4.2.min.js HTTP/1.1 Host: tehspb.kodeks.ru User-Agent: squidclient/4.9 Accept: */* Connection: close If-None-Match: "800439-72175-1534779018000" Response: HTTP/1.1 304 Not Modified Server: nginx/1.4.6 (Ubuntu) Date: Wed, 22 Jan 2020 05:48:20 GMT Content-Type: text/javascript; charset=UTF-8 Content-Length: 0 Connection: close X-PaperRoute: Node ETag: "800439-72175-1534779018000" last-modified: Mon, 20 Aug 2018 15:30:18 GMT Access-Control-Allow-Origin: * Cache-Control: no-cache Aaron's analysis in comment #11 of that bug report Alex linked to is exactly correct. The Content-Length header should not be present at all in these 304. The case where a Content-Length header would be valid here is also the case where the ETag should have changed - meaning the status should be 200 and the new content+ETag delivered (not a 304 at all). IIRC we had a more recent proposal for some work towards identifying these broken 304 cases and re-fetching the content. But no idea whether that has made progress past the early brainstorming. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
