Is -messaging part of the core definition of HTTP?

[martinthomson]

Sorry for this being a question.

I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible.

There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that.

Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: TRACE recommends "message/http" and content codings prohibit overlap with transfer codings. These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.

[reschke]

I agree that this would be good.

[reschke]

1. A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD.
2. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.

[mnot]

History in #335 and linked issues.

[martinthomson]

Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.