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