`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>
The bad arithmetic didn't result in wrong or insecure behavior
(there were no out-of-bound accesses and forward progress was
still being made because of the outer loop) but it did regress
the performance of header field parsing rather massively.
Taking the test suite as an example: the inner fast path loop
was skipped over 4.4 million times, falling back to the outer
slow path loop. After this commit that only happens about
2,000 times - a 2,200-fold reduction.
Fixes: https://github.com/nodejs/http-parser/issues/473
PR-URL: https://github.com/nodejs/http-parser/pull/474
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Commit 2a0d106 ("http_parser: revert `memchr()` optimization")
introduced a -Wsign-compare warning that manifests itself with
gcc 7.4.0 but not older versions.
The type of p - q is signed when p and q are pointers and was
compared against an unsigned type. Its actual value is always >= 0
however and can be safely cast to size_t.
Fixes: https://github.com/nodejs/http-parser/issues/471
PR-URL: https://github.com/nodejs/http-parser/pull/472
Reviewed-By: Fedor Indutny <fedor.indutny@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>
Changes:
* Cache parser->nread in a local variable (same optimization that was
already in place for parser->state).
* Move the cost of the conditional branch for spaces in tokens out of
the fast-tokenizer implementation and into the strict-tokenizer
implementation.
Together, these changes yield a ~15% increase in MB/s and req/s in
the included bench program on x86_64.
PR-URL: https://github.com/nodejs/http-parser/pull/422
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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>
The boilerplate included attribution to NGINX that created confusion
because NGINX is distributed under a different license (BSD, not MIT.)
To the best of everyone's knowledge, no actual NGINX code remains.
Remove the attribution to clear up the confusion.
Fixes: https://github.com/nodejs/http-parser/issues/389
PR-URL: https://github.com/nodejs/http-parser/pull/390
Reviewed-By: Fedor Indutny <fedor@indutny.com>
can use same switch-lookup for '-' char case
move PROPFIND and PURGE to be next to the other P methods
change IS_ALPHA(ch) to A <= ch <= Z
(very slight optimization, only uppercase will match in switch)
PR-URL: https://github.com/nodejs/http-parser/pull/323
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
- 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>
Microsoft C++ compiler fails when this assert appears before the
declarations. Moved assert to appear after the declarations.
PR-URL: https://github.com/nodejs/http-parser/pull/293
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>
Fixes a header parsing bug for obstext characters (> 0x80)
Adaption of nodejs/node@954a4b4b:
Author: James M Snell <jasnell@gmail.com>
Date: Mon Feb 15 09:40:58 2016 -0800
deps: update to http-parser 2.6.2
Fixes http-parser regression with IS_HEADER_CHAR check
Add test case for obstext characters (> 0x80) is header
PR-URL: https://github.com/nodejs/node/pull/5237
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
PR-URL: https://github.com/nodejs/http-parser/pull/287
Reviewed-By: James M Snell <jasnell@gmail.com>
Use a switch and a macro to branch parsing of HTTP methods.
Easier to read and much shorter.
In this commit, the order of branches dispatching is the same as in the
original code, to ease review. Reordering branches by descending
frequency will improve speed too.
PR-URL: https://github.com/nodejs/http-parser/pull/273
Reviewed-By: Fedor Indutny <fedor@indutny.com>
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>
The struct must be zero-initialized, but this wasn't explicitly stated
anywhere in headers. Introduce `http_parser_url_init` API method that
will do it.
Fixes: #209
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
PR-URL: https://github.com/nodejs/http-parser/pull/225
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>
Fedor Indutny
Ben Noordhuis
Sergey Zolotarev
Olga Batyshkina
cjihrig
dnartz
Matt Klein
Matthias Loy
Brian Pane
Welling Guzman
Stefano Sambi
Pierce Lopez
André Klitzing
Thomas 'fake' Jakobi
Brian White
Jonathan Marler
Johan Bergström
Olivier Mengué
James M Snell
Sebastian Philipp
Ivan Enderlin
Tatsuhiro Tsujikawa
dlmeetei@gmail.com
Jan Schär
Daniel Knoppel (Phusion)
Kjell Schubert
Romain Giraud
Jon Kolb