- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Sat, 15 Oct 2016 09:14:38 +0000
- To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- cc: HTTP working group mailing list <ietf-http-wg@w3.org>, Matt Menke <mmenke@google.com>, Poul-Henning Kamp <phk@varnish-cache.org>
--------
In message <20161015070704.792DC138A6@welho-filter2.welho.com>, Kari Hurtta wri
tes:
>
>> The token rule in RFC7230 already includes asterisks, so I don't think identifier or token_or_asterix
>> is needed.
>
>Yes.
The "_or_asterix" comes from the intial analysis where I used a much
tighter specification for the name of the dictionaries in the list.
But I forgot to clean this up entirely in the normative ABNF, specifically
it should be:
identifier = token [ "/" token ]
>> 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<
This is, but my draft does not define if the two values should be
appended as one list (most sane headers) or treated as separate
instances (Cookie header).
I'm personally against repeat headers, because you cannot act on
a header until you've seen/decompressed the full set of headers.
>> Or:
>>
>> Foo: >bar<, >baz<
This is not inside Common Structure, and I don't think we should
make space for it.
>3.2.2. Field Order
>https://tools.ietf.org/html/rfc7230#section-3.2.2
>
>| A recipient MAY combine multiple header fields with the same field
>| name into one "field-name: field-value" pair, without changing the
>| semantics of the message, by appending each subsequent field value to
>| the combined field value in order, separated by a comma.
Yes, this is what I don't like, and I think we should limit the application
of it by all possible means.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Saturday, 15 October 2016 09:15:05 UTC