Re: WGLC Review of HTTP (-semantics)

On Sat, Feb 06, 2021 at 05:40:01PM -0800, Roy T. Fielding wrote:
> > 1. Multiple trailer sections
> > 
> > The document describes trailers in a way that permits multiple field
> > sections to be sent, starting from the point after the end of the header
> > section following a final status code.
> 
> To be clear, it doesn't permit them to be sent. It permits them to be
> understood.
> 
> It gives us a framework in which to understand 0, 1, ..., N sections
> containing
> metadata, as opposed to the HTTP/0.9 model of 0 sections, HTTP/1.0 model
> of one header section, or the HTTP/1.1 model of one header section and
> potentially one trailer section. In short, the description in Semantics allows
> for extensions to be defined in the future that can send N sections without
> having to re-publish the core HTTP specs.

I'd say that spontaneously I'm not fond of this because I haven't given
it much thought yet, but I do see how that could be useful in the future,
and I agree that semantics must be defined before there's any opportunity
for an extension, so it's better to keep this in I guess.

> > 2. Upgrade
> > 
> > Only HTTP/1.1 supports Upgrade in any meaningful sense.  It's possible that
> > HTTP/1.1 is the only version that could use Upgrade in that way.  The way
> > that this mechanism is designed essentially depends on a paradigm that is
> > unique to that version.  I don't think that this is a big deal, but I would
> > prefer to see Sections 7.8, 15.2.2, 15.5.22, and 16.7 moved to the
> > messaging document.  As far as I can tell, these sections are the only ones
> > to mention anything related to Upgrade (aside from listings in the IANA
> > considerations), so my guess is that this would not be especially
> > disruptive a move.  (As these are trailing sections, it probably does not
> > even affect inbound citations to this document, thinking about QUIC.)
> 
> I don't think Upgrade has any such limitations. I understand why the
> folks implementing h2 were not interested in allowing Upgrade be
> signaled on a stream, even when only one stream is in use, but there
> is nothing (aside from the spec) preventing Upgrade from functioning
> in h2. Likewise, there is nothing 1.1-specific about HTTP/3 clients
> indicating that they support some future protocol within QUIC
> streams via the Upgrade header field, as opposed to the far more
> brittle settings.

Upgrade is a difficult topic because it's actually a declaration of a
drop of semantics. If it was seen as a downgrade rather than an upgrade
it would be clearer (i.e. drop of HTTP semantics).

In haproxy, we're using "multiplexers" to implement the transport part
of the protocol, and we have a version-agnostic HTTP semantic layer
between both ends. We support Upgrade for HTTP/1.1, CONNECT for HTTP/1
and HTTP/2, and map any of them to a "tunnel" in the middle, this
tunnel being associated with an optional protocol (which is how we
can map H2's CONNECT to H1's Upgrade for RFC8441, and conversely). For
me it's pretty clear that Upgrade as it is used is pretty much HTTP/1.1-
specific, there's even the "Connection: Upgrade" requirement. However
the notion of upgraded stream or connection is more generic. I think
that the Upgrade header is to the upgraded protocol what the Host
header is to the authority: just a protocol-specific way to convey it.
But as long as it's possible to reliably negotiate the protocol to
switch to and drop the HTTP semantics, I think various methods are
interoperable and the way we name them or document them will not make
much a difference, since historically at least these two solutions
have existed anyway.

Cheers,
Willy

Received on Sunday, 7 February 2021 07:45:30 UTC