Last Comment Bug 168988 - HTTP should reject URLs that lack a hostname.
: HTTP should reject URLs that lack a hostname.
Status: VERIFIED FIXED
: topembed+
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: mozilla1.2beta
Assigned To: Darin Fisher
:
Mentors:
http:///
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-16 10:57 PDT by Darin Fisher
Modified: 2002-10-02 06:49 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 patch (612 bytes, patch)
2002-09-25 19:55 PDT, Darin Fisher
dougt: review+
rpotts: superreview+
Details | Diff | Splinter Review

Description Darin Fisher 2002-09-16 10:57:26 PDT
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.
Comment 1 tenthumbs 2002-09-16 12:38:15 PDT
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.
Comment 2 Darin Fisher 2002-09-16 14:12:28 PDT
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.
Comment 3 Bradley Baetz (:bbaetz) 2002-09-16 15:15:55 PDT
I'm reasonably sure that even the very-contradictory uri spec requires a
hostname here...
Comment 4 Darin Fisher 2002-09-25 19:55:08 PDT
Created attachment 100685 [details] [diff] [review]
v1 patch
Comment 5 Darin Fisher 2002-09-25 19:56:47 PDT
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.
Comment 6 Darin Fisher 2002-09-25 19:59:15 PDT
i of course meant:

this patch verifies that the _hostname_ is not empty before...
Comment 7 Doug Turner (:dougt) 2002-09-26 06:24:48 PDT
Comment on attachment 100685 [details] [diff] [review]
v1 patch

r=dougt
Comment 8 rpotts (gone) 2002-09-30 16:47:36 PDT
Comment on attachment 100685 [details] [diff] [review]
v1 patch

sr=rpotts@netscape.com
Comment 9 Darin Fisher 2002-09-30 17:16:22 PDT
fixed-on-trunk
Comment 10 Tom Everingham 2002-10-01 16:27:27 PDT
verified:  10/01/02 trunk, winNT4, linux rh6, mac osX
Comment 11 Sam J. Fleet 2002-10-02 06:14:40 PDT
So, you don't meant that "HTTP should reject URLs that lack a hostname" like 
this "http://129.21.2.233" as oppose to "http://www.rit.edu"?
Comment 12 Darin Fisher 2002-10-02 06:49:49 PDT
nope, this check just avoids sending out a request for http:/// to a proxy server.

Note You need to log in before you can comment on or make changes to this bug.