Re: draft-ietf-httpbis-jfv: what's next

I think the draft looks good, but have a couple comments:

The token rule in RFC7230 already includes asterisks, so I don't think identifier or token_or_asterix is needed.

Would it make sense to codify behavior if a part of a h1_common_structure value fails to parse, at least if it uses the proposed "><" format)?  I suspect what browsers do is inconsistent here, and having some official rule (ignore the entire element vs ignore the entire line vs ignore the broken parameter) seems like it would be worth having?  I'd go with throw away the entire header line, if it uses the new format and that happens, since that's easiest to standardize on.

I think it's unfortunate that the HTTP/1 serialization can't distinguish between identifiers, numbers, and timestamps.  It means that per-specific-header logic will have to be responsible for that extra round of parsing for HTTP/1 headers.  If H2/QUIC goes with a fancier binary encoding scheme that doesn't have that issue, that means that those formats would not have to do the extra found of parsing, which seems a bit weird, but I don't see a good way around that asymmetry.

On single/multiple headers:  The draft has a comment about this, but it doesn't really comment on whether the following is legal:

Foo: >bar<
Foo: >baz<

Or:

Foo: >bar<, >baz<

According to Chrome's current logic, both would be valid and are equivalent (Assuming >< is treated like quotes, with extra logic for nested quotes, and "Foo" isn't one of a small set of non-coalescing headers).  Is different behavior intended in these two cases?

Received on Friday, 14 October 2016 19:38:14 UTC