[Webkit-unassigned] [Bug 117735] [curl] Improve multipart response handling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=117735





--- Comment #7 from Peter Gal <galpeter at inf.u-szeged.hu>  2013-07-25 08:04:19 PST ---
(In reply to comment #6)
> (From update of attachment 206765 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=206765&action=review
> 
> Overall this looks good.  There are a few minor style problems that need to be corrected.  I'm also not sure about the meaning of 'strict' header parsing.  It would be helpful to know if there are documented rules for when something should be parsed strictly or not.
> 
> > Source/WebCore/platform/network/HTTPParsers.cpp:608
> > +size_t parseHTTPHeader(const char* start, size_t length, String& failureReason, AtomicString& nameStr, String& valueStr, bool strict)
> 
> Who governs whether we are parsing in 'strict' mode or not?  Is this documented by an RFC?
> 

In this case if the strict is true it'll mean that we strictly enforce the HTTP headers to end with \r\n. If it is false we'll allow headers which are only separated by a \n. The RFC states that the headers should be separated by a \r\n but there are servers and testcases that doesn't follow this rule (sadly).

Actually I'm not sure if we should allow such headers, but in there are other places in the curl backend where it is allowed, and also I think the other network backends (libsoup for example) allows such headers.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.