Commit Graph

7 Commits

Author SHA1 Message Date
Ruben Bridgewater
e038d6a1cd
test: refactor common.expectsError
This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.

The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.

This has the side effect that `common` is used significantly less
frequent.

PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
2019-12-31 15:54:20 +01:00
Robert Nagy
5f80df8820 http: do not emit end after aborted
IncomingMessage will no longer emit end after aborted.

PR-URL: https://github.com/nodejs/node/pull/27984
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2019-10-13 19:04:44 -07:00
Anna Henningsen
ba565a3734 http: improve parser error messages
Include the library-provided reason in the Error’s `message`.

Fixes: https://github.com/nodejs/node/issues/28468

PR-URL: https://github.com/nodejs/node/pull/28487
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
2019-07-05 22:36:53 -07:00
ZYSzys
dcc5e51e1c tools: force common be required before any other modules
PR-URL: https://github.com/nodejs/node/pull/27650
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
2019-05-13 19:39:34 +08:00
Ruben Bridgewater
f8763bb077
benchmark,doc,lib,test: capitalize comments
PR-URL: https://github.com/nodejs/node/pull/26483
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
2019-03-10 00:44:40 +01:00
Yann Hamon
c957b05177
http: send connection: close when closing conn
HTTP/1.1 mandates connections which do not support keep-alive and
close the connection send the connection: close header, see
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10

This page also provides more information:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection

I understand that HTTP/1.1 defaults to keep-alive - and that the
Connection: close header is required when closing a connection.

This adds the Connection: close header in the 400 and 414
responses sent on client errors.

PR-URL: https://github.com/nodejs/node/pull/26467
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
2019-03-09 00:23:48 +01:00
Albert Still
bcf2886a84 http: return HTTP 431 on HPE_HEADER_OVERFLOW error
Instead of returning a generic 400 response when the
max header size is reached, return a 431 Request Header
Fields Too Large.

This is a semver-major because it changes the HTTP
status code for requests that trigger the header
overflow error.

PR-URL: https://github.com/nodejs/node/pull/25605
Fixes: https://github.com/nodejs/node/issues/25528
Refs: https://tools.ietf.org/html/rfc6585#section-5

Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2019-02-01 19:48:23 +01:00