-
Notifications
You must be signed in to change notification settings - Fork 567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TRACE response format #827
Comments
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. |
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:
|
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? |
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. |
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) |
I would prefer "Can use any format. By the way, message/http exists." |
Given the text in -semantics:
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? |
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) |
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. |
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:
is still present. What response format should an h2 server use?
The text was updated successfully, but these errors were encountered: