- From: <wizard@newsreports.org>
- Date: Sat, 31 Jan 2004 07:02:48 -0500
- To: paulle@windows.microsoft.com, ietf-http-wg-request@w3.org, HTTP Working Group <ietf-http-wg@w3.org>
Well, I've had second thoughts. It has occurred to me that we are really looking at two different things, both being referred to as URL's. 3.2.2 is really more akin to a formal specification of what the request-uri of 5.1.2 should look like in the HTTP protocol. Certainly, it specifies that the host is mandatory, yet hosts are often omitted in HTML documents. Howver, there is nothing inherently wrong with username:password appearing in an *HTML* document, and the browser subsquently interpreting that information to form a Authorization: header in response to a WWW-Authenticate: challenge. As we all know, http://username:password@www.example.com is not sent literally over the wire. And neither is http://www.example.com:8080/index.html?var=something, but rather GET /index.html?var=something HTTP/1.1 Host: www.example.com and the client *knows* automagically to connect to port 8080. To make a long story short, as long as the over the wire protocol is respected, is there really anything proscriptive in 2616 with regard to the appearance in an *HTML* document? The only thing that username:password@ causes in *HTTP* when the browser finally gets around to it, is the addition of: Authorization: blahblahblah in response to WWW-Authenticate. To go really far out in left field, there is nothing in 2616 to stop an html author from displaying the username/password on the page and asking the user to key it in when challenged. Nor does it say that IE cannot store a username and password for the "remember password function". If the argument is that 3.2.2 prescribes the semantics of the href attribute of the HTML <A> tag, then there is a lot of broken HMTL code out there because it quite common to use either root relative, or relative URL's in href attributes. The fact that common browsers know what to do about this would be due to their interpretative abilities. By extension, username:password@ is also an interpretive ability. And it's all in the HTML, it's got nothing to do with HTTP over the wire. At least in practical terms. BTW, it was mentioned in a forum elsewhere that this change would break a lot of Paypal payment links. I don't know myself because I do not have a Paypal vendor account. What I am really asking is that the distinction be made between what HTTP is, and running HTTP from HTML documents. A minor distinction, but perhaps a useful one. Respectfully, Bob wizard@newsreports.org wrote: > > Ok, uncle :) > > I see what I believed and what is fact are > two different things. I really should not > have been so lazy about pulling up 2616. > > My apologies to one and all. > > I guess it's back to the drawing boards > for my stuff. Whether it currently works > or not is moot (sniff!), if it is non-compliant > then, I guess I gotta suck it up. > > Best Regards, > > Bob > > Paul Leach wrote: > > > > RFCs 2616 and 2396 (which updates 1738) are clear that username:password is > > NOT legal in HTTP URLs. > > > > >From 2616: > > > > 3.2.2 http URL > > > > The "http" scheme is used to locate network resources via the HTTP > > protocol. This section defines the scheme-specific syntax and > > semantics for http URLs. > > > > http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] > > > > If the port is empty or not given, port 80 is assumed. The semantics > > are that the identified resource is located at the server listening > > for TCP connections on that port of that host, and the Request-URI > > for the resource is abs_path (section 5.1.2). The use of IP addresses > > in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If > > the abs_path is not present in the URL, it MUST be given as "/" when > > used as a Request-URI for a resource (section 5.1.2). If a proxy > > receives a host name which is not a fully qualified domain name, it > > MAY add its domain to the host name it received. If a proxy receives > > a fully qualified domain name, the proxy MUST NOT change the host > > name. > > > > > -----Original Message----- > > > From: ietf-http-wg-request@w3.org > > > [mailto:ietf-http-wg-request@w3.org] On Behalf Of > > > wizard@newsreports.org > > > Sent: Friday, January 30, 2004 5:27 PM > > > To: Michael Howard; ietf-http-wg-request@w3.org; HTTP Working > > > Group; Michael Howard > > > Cc: Dave Kristol > > > Subject: Re: Microsoft to Strike IE URL Passwords > > > > > > > > > Michael, > > > > > > Off the top of my head, so I may be totally off base :) > > > > > > But, username:password@example.com is a valid uri in the http > > > protocol. It follows, therefore, that it is a valid HREF > > > value in an <A> tag. If the browser then does something other > > > than is intended when the <A> tag is invoked, then it is > > > arguably non-compliant. > > > > > > That is my argument in a nutshell. Now, I could get all > > > scholarly and dig out all the references, but this would make > > > the argument much more obtuse and hard to follow. I would not > > > advance anything that I did not feel was supported in the > > > relevant RFC's. > > > > > > Now, as a matter of practicality, IE is a Microsoft product > > > and Microsoft can do as it wishes. Further, it can be argued > > > that this is not a common usage of a uri. But, it *is* used > > > and useful. To break it would be a shame. Especially if the > > > shortcomings can be solved another way. > > > > > > To reiterate, the two problems that are referenced fall into > > > the category of program bug, and rendering that is suitable > > > for the majority of users. This is not a failing in the > > > usage of the particular uri format at all. > > > > > > By kicking up a fuss as early as possible, I am hoping that > > > more consideration will be given to a non-intrusive fix that > > > will leave the intended functionality intact. > > > > > > Best Regards, > > > > > > Bob > > > > > > > > > Michael Howard wrote: > > > > > > > > The plan, and it may change, is to nix username:pwd@ in a > > > url. Correct > > > > me if I'm wrong, but this format is only valid for ftp, not http. > > > > > > > > Cheers, Michael > > > > > > > > [Writing Secure Code 2nd Edition] > > > > http://www.microsoft.com/mspress/books/5957.asp > > > > [Protect Your PC] http://www.microsoft.com/protect [Blog] > > > > http://blogs.msdn.com/michael_howard > > > > > > > > -----Original Message----- > > > > From: wizard@newsreports.org [mailto:wizard@newsreports.org] > > > > Sent: Friday, January 30, 2004 1:35 PM > > > > To: ietf-http-wg-request@w3.org; HTTP Working Group; Michael Howard > > > > Cc: Dave Kristol > > > > Subject: Re: Microsoft to Strike IE URL Passwords > > > > > > > > Michael, > > > > > > > > Is this not really a rendering problem? > > > > > > > > This remark includes the "%01" problem, and user perception > > > that the > > > > leading part before the "@" is the web site. > > > > > > > > The first is a problem internal to the browser, and should be fixed. > > > > > > > > The second is a rendering problem, in > > > > that many users do not know the difference. > > > > Therefore, it is more useful to present the url to the user without > > > > the credentials portion. > > > > > > > > If the embedded credentials are permitted in a valid url, > > > and that url > > > > is embedded as, for example, the href of an <a> tag, and > > > the browser > > > > does not retrieve the referenced resource, then the browser > > > is broken. > > > > > > > > Removing this valid behaviour will, in some cases, break > > > many months > > > > of work. I am involved in one such case. > > > > > > > > Bob > > > > > > > > Michael Howard wrote: > > > > > > > > > > Only the form: > > > "http(s)://username:password@server/resource.ext" is > > > > > being removed; basic auth is untouched. > > > > > > > > > > Cheers, Michael > > > > > > > > > > [Writing Secure Code 2nd Edition] > > > > > http://www.microsoft.com/mspress/books/5957.asp > > > > > [Protect Your PC] http://www.microsoft.com/protect [Blog] > > > > > http://blogs.msdn.com/michael_howard > > > > > > > > > > -----Original Message----- > > > > > From: ietf-http-wg-request@w3.org > > > > > [mailto:ietf-http-wg-request@w3.org] > > > > > On Behalf Of Dave Kristol > > > > > Sent: Thursday, January 29, 2004 11:38 AM > > > > > To: HTTP Working Group > > > > > Subject: Microsoft to Strike IE URL Passwords > > > > > > > > > > <http://www.internetnews.com/dev-news/article.php/3305741> > > > > > > > > > > If I understand this article correctly, it sounds like MS IE will > > > > > remove support for Basic Authentication. While we all agree that > > > > > cleartext passwords are evil, this sounds to me like it > > > will create > > > > > a major compatibility problem at sites that use Basic. And note > > > > > that it > > > > > > > > > covers Basic over SSL, too, where the passwords would *not* be > > > > cleartext. > > > > > > > > > > Dave Kristol > > > > > > > > -- > > > > > > > > ------------------------------------------------------------------ > > > > FREE DOWNLOADS > > > > > > > > iis bandwidth protection -- http://coldlink.com/ > > > > > > > > iis password protection -- http://wanderware.com/ > > > > > > > > ------------------------------------------------------------------ > > > > > > > > .. > > > > > > -- > > > > > > > > > ------------------------------------------------------------------ > > > FREE DOWNLOADS > > > > > > iis bandwidth protection -- http://coldlink.com/ > > > > > > iis password protection -- http://wanderware.com/ > > > > > > ------------------------------------------------------------------ > > > > > > > > > > > > > > > .. > > > > > > > > -- > > ------------------------------------------------------------------ > FREE DOWNLOADS > > iis bandwidth protection -- http://coldlink.com/ > > iis password protection -- http://wanderware.com/ > > ------------------------------------------------------------------ > > .. -- ------------------------------------------------------------------ FREE DOWNLOADS iis bandwidth protection -- http://coldlink.com/ iis password protection -- http://wanderware.com/ ------------------------------------------------------------------ ..
Received on Saturday, 31 January 2004 06:59:28 UTC