W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

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

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Fri, 29 Jul 2011 09:45:41 +1000
To: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E11289634AD7@WSMSG3153V.srv.dir.telstra.com>
>> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:46 GMT