IPv6 scoped address contains Zone ID, which is appended to IPv6
address after '%' separator. RFC 6874 says that Zone ID after '%'
must consist of 1*(unreserved or pct-encoded). This commit adds this
IPv6 Zone ID support.
PR-URL: https://github.com/joyent/http-parser/pull/253
Reviewed-By: Fedor Indutny <fedor@indutny.com>
http_parse_host() depends on `u->field_data[UF_HOST]`, but this
if() allowed the method to be called if only
`u->field_data[UF_SCHEMA]` was set, resulting in use of
unintialized pointers.
PR-URL: https://github.com/joyent/http-parser/pull/246
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Do explicit casts from/to enums, convert type of `memchr`'s return value
to `const char*`.
PR-URL: https://github.com/joyent/http-parser/pull/213
Reviewed-By: Bert Belder <bertbelder@gmail.com>
test.c:2210:9: warning: Value stored to 'char_len' is never read
char_len = 2;
^ ~
test.c:2921:3: warning: Value stored to 'pass' is never read
pass &= (parsed == 0);
^ ~~~~~~~~~~~~~
Reviewed-By: Fedor Indutny <fedor@indutny.com>
RFC-7230 Sec 3.2.4 expressly forbids line-folding in header
field-names.
This change no longer allows obsolete line-folding between the
header field-name and the colon. If HTTP_PARSER_STRICT is unset,
the parser still allows space characters.
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Always discard leading whitespace in a header value, even if it
is folded.
Pay attention to values of interesting headers (Connection,
Content-Length, etc.) even when they come on a continuation line.
Add a test case to check that requests and responses using only LF
to separate lines are handled correctly.
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.
Ivan Enderlin
Tatsuhiro Tsujikawa
dlmeetei@gmail.com
Jan Schär
Daniel Knoppel (Phusion)
Guo Xiao
Fedor Indutny
Kjell Schubert
Umorrian
Jay Satiro
Romain Giraud
Akagi201
Jon Kolb
Timothy J Fontaine
Alexis La Goutte
Jeff Pinner
Marc O'Morain
Maciej Małecki
George Miroshnykov
Helge Heß
Mark Koopman
Alex Kocharin
Rex Feng
Alex Butum
Vinnie Falco
Fedor Indutny
David Wragg