Note: There are a few cases of duplicates in user autocompletion which are being worked on.

HTTP should reject URLs that lack a hostname.

VERIFIED FIXED in mozilla1.2beta

Status

()

Core
Networking: HTTP
P3
normal
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: Darin Fisher, Assigned: Darin Fisher)

Tracking

({topembed+})

Trunk
mozilla1.2beta
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
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.

Updated

15 years ago
Keywords: topembed+
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
Keywords: mozilla1.0.2, mozilla1.2, nsbeta1
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta

Comment 1

15 years ago
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.
(Assignee)

Comment 2

15 years ago
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...
(Assignee)

Comment 4

15 years ago
Created attachment 100685 [details] [diff] [review]
v1 patch
(Assignee)

Comment 5

15 years ago
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.
(Assignee)

Updated

15 years ago
Keywords: patch
(Assignee)

Comment 6

15 years ago
i of course meant:

this patch verifies that the _hostname_ is not empty before...

Comment 7

15 years ago
Comment on attachment 100685 [details] [diff] [review]
v1 patch

r=dougt
Attachment #100685 - Flags: review+

Comment 8

15 years ago
Comment on attachment 100685 [details] [diff] [review]
v1 patch

sr=rpotts@netscape.com
Attachment #100685 - Flags: superreview+
(Assignee)

Comment 9

15 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 10

15 years ago
verified:  10/01/02 trunk, winNT4, linux rh6, mac osX
Status: RESOLVED → VERIFIED

Comment 11

15 years ago
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"?
(Assignee)

Comment 12

15 years ago
nope, this check just avoids sending out a request for http:/// to a proxy server.
You need to log in before you can comment on or make changes to this bug.