Trying to summarize the status of the discussion and where the issues are with the current Upgrade implementation.
Clarified: A. any 100 must be sent out *before* a 101 response B. request bodies are to be read in the original protocol, input filters like chunk can be used, indeed are necessary, as if the request is being processed normally C. if a protocol supports upgrade on request bodies is up to the protocol implementation and needs to be checked in the "propose" phase Open: 1. Protocols like Websocket need to take over the 101 sending themselves in the "switch protocol" phase. (correct, Jacob?). Should we delegate the sending of the 101 to the protocol switch handler? 2. General handling of request bodies. Options: a setaside in core of up to nnn bytes before switch invocation b do nothing, let protocol switch handler care about it 3. When to do the upgrade dance: a post_read_request: upgrade precedes authentication b handler: upgrade only honored on authenticated and otherwise ok requests c both: introduce separate hooks? have an additional parameter? more complexity 4. status code of protocol switch handler: if we move the task of 101 sending, the switch handler might not do it and keep the connection on the "old" protocol. Then a connection close is not necessary. So, we would do the close only when the switch handler returns APR_EOF. 5. Will it be possible to migrate the current TLS upgrade handling to this revised scheme? Anything I missed? PS. Re 5: with change 1+4, a TLS upgrade switcher could install an output filter, return and have it being processed normally. The output filter would then send the 101 and do the TLS handshake. Would that work? > Am 08.12.2015 um 10:42 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>: > > >> Am 07.12.2015 um 23:42 schrieb Jacob Champion <champio...@gmail.com>: >> >> On 12/07/2015 02:30 PM, Bert Huijben wrote: >>> Is this a h2 limitation or a mod_h2 limitation? >>> >>> If I would like h2c upgrade from Subversion without an additional >>> request I would have to send the upgrade request with a very short >>> OPTIONS request that has a body. >> >> The HTTP/2 spec (RFC 7540, sec 3.2) appears to allow the sending of a >> request body in an h2c upgrade (h2 upgrades are prohibited). So it would >> appear to be a mod_http2 limitation for now. >> >> Hopefully Stefan can confirm tomorrow (it's pretty late in Germany). > > It is possible, but difficult to do unless you can read the body and set it > aside somewhere. Which again imposes an arbitrary (for the client) limit. > Experience shows that this leads to design of clients that work will in > developments, but then encounter requests usage/sites/servers that have other > limits and break. > > If Apache accepts body lengths of up to 64KB (or something configurable) and > some other server implements 8K and some third 1MB, how will that help design > of a client that, for some reason, *wants* an upgrade to succeed? > > //Stefan >
