Fix ABI breakage introduced in commit 7d5c99d ("Support multi-coding
Transfer-Encoding") by undoing the change in `sizeof(http_parser)`.
Restore the size of the `flags` field and shrink the `index` field from
7 to 5 bits. It track strings up to `strlen("Transfer-Encoding")` bytes
so 2^5 == 32 is wide enough.
Fixes: https://github.com/nodejs/http-parser/issues/502
PR-URL: https://github.com/nodejs/http-parser/pull/503
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
It doesn't matter yet, but two tests had the same name, and same test
position macro.
PR-URL: https://github.com/nodejs/http-parser/pull/497
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
`Transfer-Encoding` header might have multiple codings in it. Even
though llhttp cares only about `chunked`, it must check that `chunked`
is the last coding (if present).
ABNF from RFC 7230:
```
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
```
However, if `chunked` is not last - llhttp must assume that the encoding
and size of the body is unknown (according to 3.3.3 of RFC 7230) and
read the response until EOF. For request - the error must be raised for
an unknown `Transfer-Encoding`.
Furthermore, 3.3.3 of RFC 7230 explicitly states that presence of both
`Transfer-Encoding` and `Content-Length` indicates the smuggling attack
and "ought to be handled as an error".
For the lenient mode:
* Unknown `Transfer-Encoding` in requests is not an error and request
body is simply read until EOF (end of connection)
* Only `Transfer-Encoding: chunked` together with `Content-Length` would
result an error (just like before the patch)
PR-URL: https://github.com/nodejs-private/http-parser-private/pull/4
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
An optimization was introduced in c6097e1d and 0097de58. The crux of
optimization was to skip all characters in header value until either
of CR or LF. Unfortunately, this optimization comes at cost of
inconsistency in header value validation, which might lead to security
issue due to violated expectations in the user code.
Partially revert the optimization, and add additional check to make
general header value parsing consistent.
Fix: #468
PR-URL: https://github.com/nodejs/http-parser/pull/469
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Harvey Tuch <htuch@google.com>
Before this commit `Content-Length: 4 2` was accepted as a valid header
and recorded as `parser->content_length = 42`. Now it is a parse error
that fails with error `HPE_INVALID_CONTENT_LENGTH`.
Downstream users that inspect `parser->content_length` and naively parse
the string value using `strtoul()` might get confused by the discrepancy
between the two values. Resolve that by simply not letting it happen.
Fixes: https://github.com/nodejs-private/security/issues/178
PR-URL: https://github.com/nodejs-private/http-parser-private/pull/1
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
`strtoul` will attempt to lookup the next digit up until it will stumble
upon an invalid one. However, for an unterminated string as an input
value, this results in out-of-bounds read.
Remove `strtoul` call, and replace it with simple loop.
Fix: #408
PR-URL: https://github.com/nodejs/http-parser/pull/409
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
- original fix is from daeon: https://github.com/daeon/http-parser/
"Tolerate web servers which do not return a status message in the
return response.
I have noticed this usse on several websites such downloads from
mediafire.com"
- original pull request: https://github.com/nodejs/http-parser/pull/254
- i merely added the status_cb_called unit test check, there already
is a test that triggers this without the patch (a 301 without a
reason phrase).
PR-URL: https://github.com/nodejs/http-parser/pull/367
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Only one digit is allowed for the major version and only one is
allowed for the minor version according to RFC 7230.
PR-URL: https://github.com/nodejs/http-parser/pull/366
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Returning `2` from on_headers_complete will tell parser that it
should not expect neither a body nor any futher responses on
this connection. This is useful for handling responses to a
CONNECT request which may not contain `Upgrade` or
`Connection: upgrade` headers.
See: https://github.com/nodejs/node/pull/6198
PR-URL: https://github.com/nodejs/http-parser/pull/299
Reviewed-By: Brian White <mscdex@mscdex.net>
Includes parsing improvements to ensure closer HTTP spec conformance
Adaption of nodejs/node@4f4c8ab3b4cea246d2ece6ca006fe280241d84a4:
Author: James M Snell <jasnell@gmail.com>
Date: Wed Feb 3 17:28:48 2016 -0800
deps: update http-parser to version 2.6.1
includes parsing improvements to ensure closer HTTP spec conformance
PR-URL: https://github.com/nodejs/node-private/pull/26
Reviewed-By: Rod Vagg <r@va.gg>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
PR-URL: https://github.com/nodejs/http-parser/pull/279
Reviewed-By: James M Snell <jasnell@gmail.com>
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>
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.
Ben Noordhuis
Sam Roberts
Fedor Indutny
Olga Batyshkina
Welling Guzmán
Matt Klein
Welling Guzman
Stefano Sambi
Thomas 'fake' Jakobi
Brian White
Guo Xiao
Johan Bergström
James M Snell
Olivier Mengué
Ivan Enderlin
Tatsuhiro Tsujikawa
Kjell Schubert
Jon Kolb
Alexis La Goutte
Jeff Pinner
David Wragg
Alexis Campailla
Fedor Indutny
Patrik Stutz
Chris Dickinson