Previously, if log-level is not mentioned in configuration file and
reload happens, the log level was not set to the default value NOTICE.
Instead, the log level stayed the same. This commit fixes this bug.
A well known server sends content-length: 0 in 101 response. RFC 7230
says Content-Length or Transfer-Encoding in 200 response to CONNECT
request: https://tools.ietf.org/html/rfc7230#section-3.3.3
llhttp does not include URL parser. We extracted URL parser code from
http-parser and put it under third-party/url-parser.
llhttp bd3d224eb8cdc92c6fc8f508d7bbe0ba266e8e92
In boost 1.70, deprecated get_io_context() has finally been removed.
Introduce GET_IO_SERVICE macro that based on boost version uses
old get_io_service() interface (boost < 1.70), or get_executor().context()
for boost 1.70+.
Commit based idea seen in monero-project/monero@17769db946
Pool HTTP/1.1 backend connection per address and reuse it only when
the next round robin index refers to this address. Previously if
there is a pooled connection, there is no round robin selection.
From https://www.ietf.org/rfc/rfc5280.txt
> As noted in Section 4.1.2.2, serial numbers can be expected to
> contain long integers. Certificate users MUST be able to handle
> serialNumber values up to 20 octets in length. Conforming CAs MUST
> NOT use serialNumber values longer than 20 octets.
Without this, nghttpx will fatal.
jbraeg$ openssl x509 -in ~/test_certs/client.crt -serial -noout
serial=E0CFDFC7CEA10DF8AAF715C37FAEB410
jbraeg$ curl -k --key ~/test_certs/client.key --cert ~/test_certs/client.crt https://192.168.98.100:3000/; echo
curl: (56) Unexpected EOF
...
Assertion failed: n == b.size() (shrpx_tls.cc: get_x509_serial: 2051)
2019-01-03T20:25:21.289Z 1 1 f84316ae NOTICE (shrpx_log.cc:895) Worker process: [9] exited abnormally with status 0x06; exit status 0; signal Aborted(6)
2019-01-03T20:25:21.290Z 1 1 f84316ae NOTICE (shrpx.cc:4311) Shutdown momentarily