Re: [squid-dev] [PATCH] Reject or sanitize more problematic Content-Length values

2016-09-02 Thread Alex Rousskov
On 09/02/2016 09:11 PM, Amos Jeffries wrote: > I would realy like it to be under Http:: and in http/ the rest is okay > to skip. Sounds good. I have no problems with moving that code into http/ and Http::. It is certainly appropriate, especially if you expect HTTP/2 code to benefit from this clas

Re: [squid-dev] [PATCH] Reject or sanitize more problematic Content-Length values

2016-09-02 Thread Amos Jeffries
On 3/09/2016 4:36 a.m., Alex Rousskov wrote: > On 09/02/2016 09:05 AM, Amos Jeffries wrote: >> On 2/09/2016 11:21 a.m., Alex Rousskov wrote: >>> This change handles multiple Content-Length values inside >>> one header field, negative values, and trailing garbage. Handling the >>> former required a

[squid-dev] [PATCH] Must revalidate CC:no-cache responses

2016-09-02 Thread Eduard Bagdasaryan
Hello, This patch forces Squid to always revalidate Cache-Control:no-cache responses. Squid MUST NOT use a CC:no-cache response for satisfying subsequent requests without successful validation with the origin server. Squid violated this MUST because Squid mapped both "no-cache" and "must-revalid

Re: [squid-dev] [PATCH] Reject or sanitize more problematic Content-Length values

2016-09-02 Thread Alex Rousskov
On 09/02/2016 09:05 AM, Amos Jeffries wrote: > On 2/09/2016 11:21 a.m., Alex Rousskov wrote: >> This change handles multiple Content-Length values inside >> one header field, negative values, and trailing garbage. Handling the >> former required a change in the overall Content-Length interpretation

Re: [squid-dev] [PATCH] Reject or sanitize more problematic Content-Length values

2016-09-02 Thread Amos Jeffries
On 2/09/2016 11:21 a.m., Alex Rousskov wrote: > Hello, > > Squid is violating HTTP MUSTs by forwarding messages with > problematic Content-Length values. Some of those bugs were fixed in > trunk r14215. This change handles multiple Content-Length values inside > one header field, negative valu