Subject: WGLC Review of HTTP (-semantics)

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Feb 2021 14:50:10 +1100

I just finished reading this and I have to say that this is very good.  It's a masterful work.  This is a difficult protocol to document, but this document is well-written, clearly organized, and precise.

Well, precise to exactly the extent the protocol permits, it's a protocol with lots of warts that have accumulated over its history.  But each of those is uniformly well-treated with clear explanations.

I raised a few issues and pull requests, but those were mostly minor.  I have just two comments that I think are worth raising at this level.

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.

This feature has not been implemented and deployed.  Worse, this feature *cannot* be implemented or deployed as there is no version of this protocol, or even an extension to the protocol, that allows this feature to be implemented.  Every current version either does not support trailers (0.9, 1.0) or only supports precisely one trailer section (1.1 with chunked encoding, 2, 3).

I appreciate the design as a rational, well-constructed thing.  It is very crisply defined.  However, I don't think that it has any place in a document that purports to document an interoperable standard.

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.)

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Feb 2021 07:54:19 +0100

Am 01.02.2021 um 04:50 schrieb Martin Thomson:
> ...

Context: <https://github.com/httpwg/http-core/issues/313> and
<https://github.com/quicwg/base-drafts/issues/3265>.

Seems that this was pushed out QUIC v1 because it's not defined by the
base specs. Pushing it out again of the base specs because it's not used
doesn't look totally reasonable.

Proposal to avoid confusion: state that it's not yet used in current
versions of HTTP and will require extensions.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Feb 2021 18:06:38 +1100

> versions of HTTP and will require extensions.

My understanding is that the "feature" was not ready in time for QUIC to take it.

However, as this could easily be implemented as an extension AND it differs so much from the rest of the specification in that it is impossible to deploy (as opposed to implemented, deployed, tested, we know what the limitations are, and what the common bugs look like), a counter-proposal: take it out and define it in an extension document.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Feb 2021 08:37:10 +0100

> However, as this could easily be implemented as an extension AND it differs so much from the rest of the specification in that it is impossible to deploy (as opposed to implemented, deployed, teste…

How is it "impossible to deploy"?

By moving it out, we'll make something that was supposed to be easy
(opt-in in new versions of HTTP) extremely hard instead (needs a spec
that updates a standards-track document).

+1 to clarifying, -1 to taking out.

Best regards, Julian