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.


On Fri, Jul 10, 2015 at 6:44 AM, Amos Jeffries <> 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 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

Received on Friday, 10 July 2015 14:15:36 UTC