- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Mon, 31 Aug 2009 12:31:56 -0700
04.08.2009, ? 16:47, Ian Hickson ???????(?): > I've added support for redirects. While I was at it I also added > support > for authentication. Reading the authentication part of the latest draft, I had several comments: > 9. If the client has any authentication information <...> that would > be relevant to a resource accessed over HTTP, if /secure/ is false, > or HTTPS, if it is true, on host /host/, port /port/, with /resource > name/ as the path (and possibly query parameters), then HTTP headers > that would be appropriate for that information should be sent at > this point. [RFC2616] [RFC2109] [RFC2965] I'm not sure how this part translates into actual behavior. What if there are several sets of credentials already known to the client, for example? Also, what if the client has already performed digest authentication with several nonce values? Is this meant to mimic some behavior that existing clients have for HTTP already? > If /code/, interpreted as ASCII, is "401", then let /mode/ be > _authenticate_. Otherwise, fail the Web Socket connection and abort > these steps. 407 (proxy authenticate) also likely needs to be supported. > -> If the entry's name is "www-authenticate" Obtain credentials in a > manner consistent with the requirements for handling the |WWW- > Authenticate| header in HTTP, and then close the connection (if the > server has not already done so) Some authentication schemes (e.g. NTLM) work on connection basis, so I don't think that closing the connection right after receiving a challenge can work with them. - WBR, Alexey Proskuryakov
Received on Monday, 31 August 2009 12:31:56 UTC