Re: http/1 opportunistic encryption

As also discussed in the thread on passing IP addresses, a common
implementation pattern seems to be to bolt an HTTP/2 demuxer in front of an
HTTP/1.x server, sometimes with them communicating such that the HTTP/1.x
server isn't seeing the HTTP/2 communications internals.  What I was
wondering is how people implementing this way pass along the URI elements.
:method, :path, and :authority have clear things to translate into, but
:scheme does not.  Not handling this properly is likely an implementation
bug, but I suspect it will be a common bug.

         Erik


On Fri, Jul 10, 2015 at 6:44 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 10/07/2015 4:41 p.m., Erik Nygren wrote:
> > Out of curiosity, how have current demuxer implementations been handling
> > and passing the :scheme along?  It may be that many implementations
> > are ending up in the same situation as http/1.1 here...
>
> Why would it be a problem for demuxers?
>
> * HTTP is stateless.
> * Messages are self-descriptive.
> * Annd RFC 7540 section 8.1.2.3 says:
> "
> All HTTP/2 requests MUST include exactly one valid value for the
> :method, :scheme, and :path pseudo-header fields
> "
> ... with :authority being mandatory except in certain edge cases where
> there is no domain:port applicable to the message.
>
>
> Thus HTTP/2 messages contain all parts of an absolute-URI in their
> pseudo-headers. There is intentionally zero ambiguity now about what the
> message means. Gone is the HTTP/1 scheme == transport protocol type
> linkage.
>
> Amos
>
>
>