RE: #195, was: ABNF for Authorization header not quite right

>> RFC 4559 "SPEGNO/NTLM/Negotiate" might specify that, but I don't think it can work as it makes parsing ambiguous. For instance, does the following response header include 1 scheme with 4 parameters, or 2 or 3 schemes? Is "tuv" another authentication scheme supported by this server, or a parameter of the "ABC" scheme?
>>    WWW-Authenticate: ABC xyz, a=1, qrs, tuv


> The ABNF says:
>
>     challenge   = auth-scheme 1*SP 1#auth-param
>
> so there needs to be at least one auth-param, separated by one or more SPs.

NTLM doesn't include any params initially.
A recent HTTPbis change made the 1 and only previously-required parameter 'realm' optional.
So the syntax should be adjusted not to require any params. At which point a base64 blob that isn't the first param would be ambiguous.


> That being said, we may have to rethink the use of the list production here.
>
> Keep in mind that 1#auth-param allosws
>
>       scheme auth-param
>
> but also
>
>       scheme ,auth-param
>
> because of the specific rules for empty list elements.
>
> *That* would be impossible to parse, and thus we may want not to use the
> # notation over here.

If you keep the <b64> part out of the list production it should be unambiguous:
 auth-scheme [1*SP (b64 / #auth-param)]

--
James Manger

Received on Thursday, 28 July 2011 23:46:15 UTC