HTTP should reject URLs that lack a hostname. Currently, if loading an URL via a proxy server, the HTTP code will try to load URLs like "http:///" even though we could easily determine that there is no hope that loading such an URL would result in anything meaningful.
As far as a proxy goes, I have to disagree. How the proxy resolves a URL is up to the proxy. It's a black box. The client cannot acquire any knowledge of what will happen.
tenthumbs: huh? http:/// is a meaningless URL. anyways, we're violating the HTTP/1.1 protocol by not sending a Host: header, which cannot be sent in this case. i see no reason to send such a lame request to a proxy server. as for non-http requests, you could perhaps argue that blah:/// could mean something. i'm not sure if that is ok, because we'd still have the problem of what Host: header to send.
I'm reasonably sure that even the very-contradictory uri spec requires a hostname here...
this patch verifies that the URL is not empty before generating the Host header inside nsHttpChannel::Init. so, there is very little cost to this check. one negative is that there is no user feedback for this error. but that's docshell's problem.
i of course meant: this patch verifies that the _hostname_ is not empty before...
Comment on attachment 100685 [details] [diff] [review] v1 patch r=dougt
Comment on attachment 100685 [details] [diff] [review] v1 patch email@example.com
verified: 10/01/02 trunk, winNT4, linux rh6, mac osX
So, you don't meant that "HTTP should reject URLs that lack a hostname" like this "http://18.104.22.168" as oppose to "http://www.rit.edu"?
nope, this check just avoids sending out a request for http:/// to a proxy server.