Re: #327: Expect syntax

On 12/16/2011 03:22 PM, Julian Reschke wrote:
> On 2011-12-16 22:56, Alex Rousskov wrote:
>> On 12/16/2011 02:14 PM, Julian Reschke wrote:
>>
>>> OK, I did two more changes:
>>>
>>> - in the grammar, allow trailing semicolons; so that "100-continue;"
>>> isn't invalid (we have the same in Prefer)
>>
>> Any specific reason to allow that trailing semicolon? Seems like it
>> should not be allowed unless Expect is already commonly used that way.
> 
> a) there's no harm

I am sure some servers that can grok "100-continue" will fail to
recognize "100-continue;" as equivalent and respond with 417. Granted,
many of those servers are not compliant in other Expect-related ways,
but I do not think "no harm" is a 100% valid assumption in this case.


> b) it's a very easy mistake to make

Agreed, on both counts: easy and mistake.


> c) it doesn't introduce ambiguity

It kind of does. Is "100-continue" equivalent to "100-continue;" and
"100-continue;;;;;"? On an intuitive level, they should be equivalent,
but I see no explicit rules that make them equivalent, especially since
we say that 100-continue does not have parameters.


> d) for other header fields, we have evidence that parsers already do this

but I am guessing there is no evidence that senders send bare semicolons
in Expect headers.


> For Expect:, I have no data, as it doesn't seem to be used for anything
> other than "100-continue".

And that is one of the reasons making this header more complex is more
dangerous.


>> I cannot find it right now, but I think there was some text in HTTPbis
>> that talked about "cleansing" of header fields before
>> comparing/interpreting them (folding, removing BWS, and such). If that
>> text is indeed there somewhere, does it allow an implementation to
>> remove bare semicolon before comparing?
> 
> Before comparing what?

Comparing with other [cached] headers (for Vary and such) or, in this
case, comparing with the list of supported extensions (which is usually
just 100-continue).


>> Finally, I expect some currently compliant implementations to fail
>> updated tests if a bare semicolon is allowed and must be ignored.
> 
> Will those accept things like
> 
>   foo, 100-continue
> 
> or
> 
>   foo; bar="q\ux,", 100-continue

Yes, some will handle the above (and worse) because we already test them
for those cases :-)


Again, I understand that this is a very minor issue that is unlikely to
cause serious problems. It feels strange to defend a "do not change
unless there is a problem" principle in an HTTPbis effort, but I am not
trying to insist on reversing this change.


Thank you,

Alex.

Received on Friday, 16 December 2011 23:48:59 UTC