There is a discussion in httpbis mailing list which argues that
dependency tree is for client, and changing it in server side is not
what client expects.
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0416.html
Currently, we make pushed stream depend on the parent stream of
associated stream (that is main HTML in most of the cases), so that
associated stream and pushed stream become siblings. In this case, we
also observed that these resources complete each other to get its
parent weight. This means that the delivery of associated stream is
delayed by pushed streams.
So at this moment, it is not a good idea to change pushed stream
priority in a way we do currently.
This commit also fixes the bug that old configuration is still used
for worker process. The another bug fix is that inherited, but not
used fd is not closed in worker process. That makes reloading next
configuration fail if it contains the address which are leaked into
worker process.
This commit implements configuration reloading with SIGHUP.
There are rough edges left:
* Rename SignalServer with more meaningful name, say, WorkerProcess.
* We should introduce global configuration object which is not
affected by configuration reloading. It should hold cmdcfgs, argc,
argv, and last worker PID.
* We should close the listener file descriptor when some operation was
failed after that.
The N-th -p options sets N-th URI's weight. If the number of -p is
less than the number of URIs, the last -p value is repeated. If no -p
is set, use default weight, 16.
Previously, we didn't retry request on connection failure. Sometimes
we hit the edge case where connection is about to lost just when we
write request. To avoid this situation, we now retry request to
failed attempt. We also add ConnectBlocker to MemcachedConnection not
to attempt to connect to memcached if connection could not be made
previously.
To reduce TTFB with large number of incoming connections, we now
intentionally accept one connection at a time, so that it does not
delay the TTFB of the existing connection. This is significant
especially for TLS connections.
For HTTP/2, read timer starts when there is no downstream, and timer
stops when there is at least one downstream. For HTTP/1, read timer
starts when request handling finished, and timer stops when request
handling starts.
Tatsuhiro Tsujikawa
Tomasz Buchert