TRACE response format

[reschke]

With the resolution of httpwg/http-core#690, http wire formats can use a response format other than "message/http".

However, the SHOULD-level requirement:

The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the content of a 200 (OK) response.

is still present. What response format should an h2 server use?

[Lukasa]

I think the SHOULD remains applicable here. We don't have a sensible alternative format to recommend for h2. If the WG wishes to work on one, we can update the document in future, but for now we inherit the -semantics SHOULD.

[reschke]

Well, you're not supposed to override a requirement from the core spec in any case.

What I was trying to say is that, when looking at this pedantically, you currently can't have a conforming H2 server with TRACE support.

You could:

• state that TRACE does not work in H2, or
• define how to map a received H2 message onto message/http (things to look for obviously are protocol version numbers, and how to map pseudo header fields back to the HTTP/1.1 message format)

[Lukasa]

Both of those sound unfortunate. Stating that TRACE doesn't work in h2 rather defeats the point of having TRACE in -semantics to begin with. Defining a mapping back to message/http, or alternatively defining a new mapping, is probably more work than we really wanted to take on with this revision.

Would it be sufficient to simply say that in response to a TRACE request a conforming H2 implementation MAY translate to message/http in whatever way it sees fit, or alternatively MAY refuse to serve the response?

[martinthomson]

Not wanting to toot my own horn, but there could be other options. I would prefer message/http over it not working in h2. But the point here is that ANY format can work. As this has a media type, we should be comfortable with any of the usual vagueness that exists around formats in HTTP. Suggesting message/http doesn't mean you take a normative dependency on it.

[Lukasa]

So do we just say "Yes, TRACE works, message/http is a SHOULD but we won't tell you how to convert it because Martin isn't done yet"? (We may editorialise the last bit of that sentence)

[martinthomson]

I would prefer "Can use any format. By the way, message/http exists."

[martinthomson]

Given the text in -semantics:

The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the content of a 200 (OK) response. The "message/http" (Section 10.1 of [Messaging]) format is one way to do so.

I was going to write something, then realized that I was just repeating that text. As HTTP/2 is not defining a new stand-alone message format that replaces "message/http", there is nothing to add other than repetition.

I think that we simply close this one with no change. @reschke, is there any specific action you think we should take?

[reschke]

Unless we want to define a new formar, or a mapping to message/http, there's nothing that can be done here (I think).

(Writing a separate doc describing the mapping would be good; it would probably help identifying other open issues, should they exist)

[martinthomson]

There's a bunch of stuff in HTTP/2 that describes the mapping to HTTP/1.1; it's piecemeal and awkward and it would be great if it didn't exist, but I don't know if it would be a good idea to excise. I do want to change that to use the generic abstractions from -semantics, but I'm not confident that that will work until it is tried out.

Closing this one and I will open an issue to track the 1.1 dependency.