The support for folding of multi-line header values does not conform to the specs. Given a request containing Multi-Line-Header: foo<CRLF> bar<CRLF> http-parser will eliminate the whitespace breaking the header value to yield a header value of "foobar". This is confirmed by the LINE_FOLDING_IN_HEADER case in tests.c. But from rfc2616, section 2.2: A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value. And from draft-ietf-httpbis-p1-messaging-25, section 3.2.4: A server that receives an obs-fold in a request message that is not within a message/http container MUST either reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream. So in the example above, the header value should be interpreted as "foo bar", possibly with multiple spaces. The current http-parser behaviour of eliminating the LWS altogether clearly deviates from the specs. For http-parser itself to confirm exactly would involve significant changes in order to synthesize replacement SP octets. Such changes are unlikely to be worth it to support what is an obscure and deprecated feature. But http-parser should at least preserve some separating whitespace when folding multi-line header values, so that applications using http-parser can conform to the specs. This commit is a minimal change to preserve whitespace when folding lines. It eliminates the CRLF, but retains any trailing and leading whitespace in the header value.make-http-max-header-size-gyp-configurable
parent
cba704cb2d
commit
5d9c382172
Loading…
Reference in new issue