On Mon, Dec 7, 2015 at 6:05 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 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). > By 'speculative read' here, I mean a look-ahead read. > 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. > > >
