On Mon, Dec 7, 2015 at 2:54 PM, Stefan Eissing <stefan.eiss...@greenbytes.de > wrote:
> ok, after some more thinking. if a tls+http/1.1 upgrade together with > Expect is indeed a use case, then, to make that work, sending the 101 needs > to become the task of the switch protocol handler itself. Then the order in > which intermediate responses are sent depends on the switched protocol. > > When writing the current code, I wanted the common tasks in core. But if > that needs to vary, we need to shift that. > 100-continue should be simple enough to implement; we can even defer the 101-switching protocols until we determine that the chunked request body "fits in memory". Roughly... 1. in the core protocol implementation, we determine that the provider is willing, so far, based on a request body of known C-L body size or of indeterminate length (no bytes read, chunked encoding) 2. we invoking a speculative connection filter read at the http protocol to network layer - that http input filter sends the 100-continue where it aught to be. That speculative read sets aside bytes read for later consumption based on the buffer it is willing to offer. The body has been read complete from the network or is still in an incomplete chunk (or would block waiting for the next chunk). 3. back in the core protocol implementation, if the http input filter still must read from the network beyond it's small buffer, no upgrade is realistically possible, then we fall out before processing the protocol switch and proceed as http/1.1. 4. alternately, if the input filter read completely, the core protocol implementation now sends the 101-switching protocols and lets the protocol implementation determine whether it injects the appropriate filters and resumes (e.g. tls), assumes authority over the core request handling and protocol (e.g. h2c), or jumps the shark entirely (e.g. echo) and has nothing more to do with the request.