Skip to content
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

Allow Lists and Dictionaries to be delimited by OWS #1173

Merged
merged 1 commit into from May 21, 2020
Merged

Conversation

mnot
Copy link
Member

@mnot mnot commented May 21, 2020

From Magnus's feedback

@mnot mnot requested review from phluid61 and bsdphk May 21, 2020 05:32
@mnot
Copy link
Member Author

mnot commented May 21, 2020

also @clelland PTAL

@kaduk
Copy link
Contributor

kaduk commented May 21, 2020

This does not instill much of a panicked reaction in me, which is probably a good sign.
I trust it is intentional to not apply a similar treatment to inner lists (which also has a prose description I had commented on previously) on the grounds of them not resembling existing top-level header field structures? That's certainly defensible, though I have to wonder whether someone will simply assume that it must be the same (not that we have much hope of changing such a person's behavior).

@phluid61
Copy link
Collaborator

How does this vibe with #998? I know we spent a bit of time on it, but it's long enough ago that I can't recall detail.

@phluid61
Copy link
Collaborator

Ah, right, I think I remember. Doing it this way means inner-list is different:

inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
             *parameter

The original motivation to remove tabs was because the above was going to be

  "(" OWS [ sf-item *( RWS sf-item ) OWS ] ")"

but there was consternation about RWS. Most of the discussion is in #983

Copy link
Contributor

@bsdphk bsdphk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think I ever saw a TAB in a HTTP header in real life, but I am OK with this.

@mnot
Copy link
Member Author

mnot commented May 21, 2020

@phluid61 #988 was where my mind went first too, but that seems to be just about in inner lists (which makes sense). I think this is separate; intermediaries that don't know about the semantics and syntactic limitations of a given field shouldn't be meddling inside it (which inner list delimitation is).

@reschke reschke self-requested a review May 21, 2020 11:42
Copy link
Contributor

@reschke reschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so that field line combination as per the Semantics spec can happen, right?

I note that https://greenbytes.de/tech/webdav/draft-ietf-httpbis-semantics-latest.html#field.order currently says:

A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma and optional whitespace. For consistency, use comma SP.

Note that it says "comma an optional whitespace", not "OWS". Depending on how you read it, it might include other whitespace characters. I believe this needs to be fixed in the Semantics spec.

@clelland
Copy link
Contributor

@reschke, I think so -- that's the only reason to allow this. Existing servers may already legitimately be using TAB when combining multiple field lines. And I suppose it makes sense, given the recent discussion about not breaking up individual list or dictionary members over multiple lines, that we don't need to replace *SP with OWS everywhere.

I'm okay with this change -- does it warrant a note in the prose somewhere that this special case only exists to accommodate field concatenation?

Note that it says "comma an optional whitespace", not "OWS". Depending on how you read it, it might include other whitespace characters. I believe this needs to be fixed in the Semantics spec.

Let's hope we don't need to add VTAB or FF to this, too :)

@mnot
Copy link
Member Author

mnot commented May 21, 2020

@reschke I don't know that that's necessary; we already define whitespace pretty clearly.

In SF, I looked at changing "whitespace", but in each case the ABNF and algorithms make it clear what we're talking about, so I don't see a strong need to disambiguate.

@reschke
Copy link
Contributor

reschke commented May 22, 2020

I'm ok with the change over here; that said, the Semantics spec could be clearer. Opened httpwg/http-core#370.

@mnot
Copy link
Member Author

mnot commented Jun 4, 2020

@bsdphk and I have been talking about this, and have come to the conclusion that this change went too far.

Specifically, steps 1 and 5 in "Parsing Structured Fields" should just be SP, not OWS, because there isn't any risk of an intermediary inserting TAB before the first field line or after the last field line; it's only between List and Dictionary members that we need to be concerned.

Reverting that part of the change also makes writing the test cases considerably simpler.

See 6842793.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants