Re: WGLC p7: Parsing auth challenges

On 2013-04-30 15:45, John Sullivan wrote:
> Julian Reschke wrote:
>> On 2013-04-29 20:55, Ben Niven-Jenkins wrote:
>>> (And if we don't get something, after whitespace elimination, which is either the end of the header field value or a token after the ",", then the value is invalid and should be rejected.)
>>
>> You could have an empty list entry, such as in
>>
>>    WWW-Authenticate: Basic realm="foo", , Basic realm="bar"
>
> Ah yes, of course. I always assume that basic #rule processing,
> including eliminating empty entries, has been done at a lower
> layer so at this level the comma "doesn't exist" - but if we're
> talking about sequences including the "," here, that is an
> inconsistent way of describing it.

#rule processing can not happen at a lower layer because if requires 
knowledge of the ABNF for "rule".

> (And if we get a non-empty string, after whitespace elimination,
> between the "," but before the earlier of either the end of the
> header field value or the next ",", which is not a token then the
> value is invalid and should be rejected.)
>
>>> If that interpretation is correct, it would be helpful to state this clearly, rather than merely infer it. (And if that interpretation is not correct, clearly relying on inference alone is unreliable!)
>>
>> The interpretation is correct. Can you make a more concrete proposal?
>>
>>> There is perhaps still the question of whether in the face of multiple WWW/Proxy-Authenticate headers, the implied "," separating their values according to #rule is still allowed to operate at both levels of the grammar, or only at the outermost (#challenge) level.
>>
>> Not sure about what you're asking. Can you provide an example?
>
> WWW-Authenticate: chal1 param1p1=val , param1p2=val, chal2 param2p1=val
>
> Should clearly be equivalent to:
>
> WWW-Authenticate: chal1 param1p1=val , param1p2=val
> WWW-Authenticate: chal2 param2p1=val

Yes.

> It also should (according to the above rules) be equivalent to:
>
> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val
>
> And of course:
>
> WWW-Authenticate: , chal1 , param1p1=val , param1p2=val, chal2 param2p1=val
>
> WWW-Authenticate: chal1 , param1p1=val , , param1p2=val, chal2 param2p1=val
>
> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val,

Yes.

> But what about:
>
> WWW-Authenticate: chal1 param1p1=val
> WWW-Authenticate: param1p2=val, chal2 param2p1=val
>
> This *could* be unambiguously parsed as equivalent to the above,
> but feels a bit shakier to allow. OTOH dumb processors assuming
> #rule might transform in or out of that form (by breaking on an
> arbitrary unencoded comma or squashing any #rule headers into a
> single instance).

Yes. It's invalid (each header field instance needs to conform to 
#challenge), but folding it into a single string may make it valid-

> On that matter I just also noticed:
>
> WWW-Authenticate: chal2
> WWW-Authenticate: param2p1=val
>
> Which looks similar but is probably disallowed by the grammar as
> it stands: the param list is optional, but if present must be
> separated by 1*SP (and any such you attempted to put in wouldn't
> form part of field-value.)

It's as invalid as the previous example.

> Going back up a bit, compare:
>
> Apparently allowed:
> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val
>
> Apparently invalid:
> WWW-Authenticate: chal1, param1p1=val , param1p2=val, chal2 param2p1=val
> ...

Yes.

The syntax for WWW-A is a big mess. Not sure what we can do here in the 
spec though.

Best regards, Julian

Received on Tuesday, 30 April 2013 14:06:42 UTC