On 11/09/2016 08:16 AM, Amos Jeffries wrote: > On 9/11/2016 3:05 a.m., Eduard Bagdasaryan wrote: >> Also simplified and fixed headers isolating code while dealing with >> empty (i.e. zero header fields) headers. Old httpMsgIsolateHeaders() >> tried to re-implement header end detection/processing logic that is >> actually covered by headersEnd(). Old httpMsgIsolateHeaders() could >> return success for some garbage input (e.g., a buffer of several CRs) >> even if no end of headers was found.
> Careful there. Since HttpMsg is actually HTTP parse logic a buffer > containing several CR's can be a valid mime block (just empty). CR is > part of BWS/OWS in HTTP. Amos, Do you agree that a buffer consisting of several CRs and nothing else must not result in httpMsgIsolateHeaders() returning 1 (i.e. "success")? The above preamble text is trying to say that the old httpMsgIsolateHeaders() could return 1 in that invalid-input case. The text should be rephrased for clarity if that is not how you interpreted it. Suggestions welcomed. In this context, the "HTTP header(s)" is defined as *( header-field CR?LF ) CR?LF where CR?LF is either CRLF or just LF. Old httpMsgIsolateHeaders() and new HttpHeader::Isolate() must extract the mime block (i.e., the *(header-field CR?LF) part) but only if headersEnd() finds the end of the HTTP header first. The old httpMsgIsolateHeaders was buggy. If you believe HttpHeader::Isolate() is buggy, please speak up! HTH, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev