- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 22 Sep 2006 16:18:32 +0200
- To: Web APIs WG <public-webapi@w3.org>
* Web APIs Issue Tracker wrote: >ISSUE-90: passwd seems underdefined in RFC2617 > >http://www.w3.org/2005/06/tracker/webapi/issues/90 > >Raised by: Anne van Kesteren >On product: XMLHttpRequest > >For the open() method I was trying to come up with error handling for the user >and password arguments. It seems that user comes down to quoted-string which is >defined in http://ietf.org/rfc/rfc2616 but passwd comes down to: > > passwd = < user's password > > >according to http://ietf.org/rfc/rfc2617 ... I am not sure which kind of error you are trying to handle. It seems the error you are trying to cover is that a password is specified in the XHR open method call which then cannot be used as password for the selected authentication scheme. As an example, xhr.open('GET', 'http://example.org', true, 'user', '\u0001'); If the authentication scheme server and client negotiate is "Basic", the client will not be able to use U+0001 in the password because for Basic only *TEXT is allowed and TEXT excludes 0x01. Other schemes might employ different rules. It seems for the Digest algorithm you cite above, this is not so well-defined in the prose. However, I don't really see how the XHR specification is affected by this, if the implementation attempts to automatically respond to authentication challenges, it should do so only if the supplied credentials are suitable for use with the negotiated scheme, and it's up to those schemes to define what's suitable. What is more of an issue is how to convert a DOMString into something that is suitable for use as password and/or username in the context of such a scheme. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Friday, 22 September 2006 14:18:49 UTC