- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Sun, 25 Mar 2007 23:47:05 +0200
- To: Scott Lawrence <scott@skrb.org>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-Id: <1174859225.16825.16.camel@henriknordstrom.net>
fre 2007-03-23 klockan 23:34 +0100 skrev Scott Lawrence: > On Fri, 2007-03-23 at 11:59 -0700, Eric Lawrence wrote: > > IE7 uses WDigest.dll, which escapes the \ into \\. > > IE6 and previous versions relied on Digest.dll, which did not escape the \. > > Why does it do that? The spec doesn't say anything about escaping > inputs to the hash... Well.. it both does and doesn't.. the specs says A1 = unq(username-value) ":" unq(realm-value) ":" passwd The notation unq(X) means the value of the quoted-string X without the surrounding quotes. username-value = quoted-string quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = <any TEXT except <">> quoted-pair = "\" CHAR There is two ambiguities in the above: a) that \ isn't excluded in qdtext requiring it to be quoted (\\). Most likely a bug in the specs as not escaping \ makes it impossible to unquote the string in a meaningful manner with \ being the escape character and valid in front of any other character (only needed infront of " and \, but valid infront of any). There is an open rfc2616bis issue for this problem. b) the unq(X) definition, which only says to remove the surrounding quotes not the \ escapes.. Most likely a bug in the specs however and it should mean the unquoted value (both surrounding quotes and escapes removed). So imho in the sensible reading of the specs the hash should be calculated on the unquoted username-value with both surrounding quotes and \ escapes removed. And any username-value encoded in the protocol should have \ escaped. Unfortunately it's not entirely clear on either point.. Regards Henrik
Received on Sunday, 25 March 2007 21:47:34 UTC