#474, was: WGLC p7: Parsing auth challenges

[Julian Reschke <[e-mail]>]

On 2013-04-30 16:06, Julian Reschke wrote:
> 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
> ...

I'd like to close this issue unless somebody can come up with a concrete 
change proposal.

Best regards, Julian