-
Notifications
You must be signed in to change notification settings - Fork 43
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
Header normalization rules #45
Comments
That syntax is defined here. That says:
So, this pretty directly covers the question, I think. The only thing I see is that this is all defined as part of media types; it would be nice if it were pulled out into a separate section about generic syntax (perhaps alongside the #rule). |
That assumes that the rules are the same for Content-Type and "similar" header fields. Can we claim that? I don't think so. |
If another header references the ABNF for parameter, I think they're buying into that handling. |
Ack. So I think the only open non-editorial question is whether parameter names are case-sensitive. The ABNF doesn't say so, and I don't believe we can just start claiming it is, even if it's the case for Content-Type. Isn't this stuff for SH? |
It is already defined:
SH wants to define things very tightly yes, but there are already existing headers that point at this ABNF. It would be good to clarify its role for them. |
Well. For Content-Type. If you just reference the ABNF for parameter, you do not automatically inherit these additional constraints. I'm all for making this re-usable,, but then we need to instruct people how to use it. There are other questions that would come up, like repeating parameter names... |
I'm going to disagree there; if someone references Repeating parameter names is indeed a separate issue. Raise it? |
Aren't we duplicating work that is supposed to happen in SH here? |
Again, SH is for new headers, not for existing ones. If you're arguing that it's not important to clarify this for existing headers, we should talk about that. |
I'm just not convinced that there's something we can clarify, for some value of "clarify". Can we discuss a concrete example? |
I think the proposal on the table is moving the text referenced above into its own section, to recognise that it's syntax (and processing) that's used by more than just media types. |
Note that in practice browsers do not use this production to parse |
I agree that it should probably be its own section on parsing header fields based on the rather painful RFC822-inspired syntax. |
in bkk: support for clarifying document |
Fixes #45. This places it as a subsection of 1.2 Syntax Notation; the intent is to also move 11. ABNF List Extension: #rule and 4.3. Whitespace there, along with any other truly generic syntax.
Hmm, I somehow missed 4.2.3. Header Field Value Components, which seems to be a good place for this sort of thing. Is it more appropriate there, or should they move down to the new section? It feels like there should be subsections, wherever these things end up. |
OK, moved into a subsection of 4.2.3. |
I updated the PR to move the real examples back to media type and forward reference them from parameters. I also reduced some of the redundant text encircling them. |
From httpwg/http-extensions#282 (see that for more context).
Are the following header fields considered equal or equivalent or are they different?
Some specializations of the header syntax permit both quoted-string and token for parameter values. If the string value after removal of quotes is the same as the token, is it the same value?
What about case folding for parameter names? Do we do that?
The text was updated successfully, but these errors were encountered: