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.
