Maurizio Lotauro wrote:
> Scrive DZ-Jay <[EMAIL PROTECTED]>:
>> Fastream Technologies wrote:
>>> Hello,
>>> Thank you both for your replies. I found the problem myself: IE6 has a bug
>>> that makes it expect a comma before Realm="...".
>> That's really weird.  Does adding the comma break it on Firefox or 
>> Opera?  The RFC does not specify that a comma is required, only 
>> whitespace, and that [param]=[value] is what denotes a parameter.
> Comma is used to separate each [param]=[value] pair.

RFC2617 says that the authentication parameters is a comma-separated 
list -- that is if there are more than one parameter, they are separated 
by comma.  In this case, Realm is only *one* parameter.  The comma after 
  the authentication method token is (or should be) invalid:

"1.2 Access Authentication Framework
HTTP provides a simple challenge-response authentication mechanism that 
MAY be used by a server to challenge a client request and by a client to 
provide authentication information. It uses an extensible, 
case-insensitive token to identify the authentication scheme, followed 
by a comma-separated list of attribute-value pairs which carry the 
parameters necessary for achieving authentication via that scheme."

Furthermore, it adds the following warning, acknowledging that more than 
one authentication token will complicate parsing:

"Note: User agents will need to take special care in parsing the WWW- 
Authenticate or Proxy-Authenticate header field value if it contains 
more than one challenge, or if more than one WWW-Authenticate header 
field is provided, since the contents of a challenge may itself contain 
a comma-separated list of authentication parameters."

And lastly, here's an example provided in section 3.5:

"3.5 Example

        HTTP/1.1 401 Unauthorized
        WWW-Authenticate: Digest
                 realm="[EMAIL PROTECTED]",

As you can see, "realm", "qop", "nonce", and "opaque" are separated by 
commas, since they are part of the parameter list; but there is no comma 
between Digest and this list, since the parameter list qualifies as a 
semantic token and the authentication tokens are whitespace delimited.

Conclusion:  I believe that IE has a bug that does not comply with 
RFC2617 -- perhaps this is originally an IIS bug of serving the headers 
wrongly; but the browser is so popular that the broken authentication 
mechanism is reproduced by most other servers and clients in order to be 


To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to