Re: WGLC p7: Parsing auth challenges

[John Sullivan <[e-mail]>]

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.

(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

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,

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).

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.)

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

John
--