Bug 32966 (relative-http)

URL: http:/ (one slash) treated as http:// rather than /

VERIFIED FIXED in mozilla1.0.2

Status

()

Core
Networking
P3
normal
VERIFIED FIXED
18 years ago
4 years ago

People

(Reporter: Jason Kane, Assigned: Andreas Otte)

Tracking

({compat, testcase, topembed})

Trunk
mozilla1.0.2
compat, testcase, topembed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

18 years ago
specifically, <form action="http:/dirone/target> (I know, a dumb thing way to do
it, but it works in communicator and ie).  Not only does it fail, it actually
gets all the way to looking up www.dirone.com

Expected result is of course that "http:/dirone/target" is functionally
identical to "/dirone/target".  (I'm tracking down the uses of this silly syntax
on my site, but I'm sure there are more of them out there).

Comment 1

18 years ago
eric, I am sure that this actually your issue.
Assignee: rods → pollmann

Comment 2

18 years ago
I wonder if <A HREF="http:/dirone/target> would have the same effect?  If so
perhaps this should go to netlib.
Keywords: 4xp
Summary: Common (but out-of-spec?) form action url's break the beast → http:/ (one slash) treated as http:// rather than /
(Reporter)

Comment 3

18 years ago
After a bit more poking around, it looks like this is the standard behavior all
over including href links and explicitly typing a URL into the browser box.  You
can see the parsing in the browser box, it goes from http:/sub/target to
http://sub/target immediatly, then tries to figure out how to handle "sub" as a
domain.

Comment 4

18 years ago
Thanks - this sounds like a general URL resolution issue.  I'll defer to Warren
on this as he knows more about it than I do.
Assignee: pollmann → warren
Component: HTML Form Controls → Networking

Comment 5

18 years ago
Personally, I'd bet that more people who did this:
<FORM ACTION="http:/mozilla.org">

Want the browser to go to http://mozilla.org than /mozilla.org.  Just my $0.02

Comment 6

18 years ago
=> andreas
Assignee: warren → andreas.otte
(Assignee)

Comment 7

18 years ago
This is from rfc 2396:

      If the scheme component is defined, indicating that the reference
      starts with a scheme name, then the reference is interpreted as an
      absolute URI and we are done.  Otherwise, the reference URI's
      scheme is inherited from the base URI's scheme component.

      Due to a loophole in prior specifications [RFC1630], some parsers
      allow the scheme name to be present in a relative URI if it is the
      same as the base URI scheme.  Unfortunately, this can conflict
      with the correct parsing of non-hierarchical URI.  For backwards
      compatibility, an implementation may work around such references
      by removing the scheme if it matches that of the base URI and the
      scheme is known to always use the <hier_part> syntax.  The parser
      can then continue with the steps below for the remainder of the
      reference components.  Validating parsers should mark such a
      misformed relative reference as an error.

By rfc 2396 this type of relative url is clearly invalid, there is a similar
type of relative url that uses this loophole in rfc1630, see bug 22251 for that
discussion.

It was decided to don't fix that problem. Instead we assume a malformed absolute
uri and try to correct it. I suggest fix the documents according to rfc 2396 by
removing the prepending http:.

Marking: Wontfix!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 8

18 years ago
verified Wontfix
Status: RESOLVED → VERIFIED

Comment 9

18 years ago
*** Bug 51055 has been marked as a duplicate of this bug. ***
I think there's a difference between entering it in the URL bar versus finding
it on an HTML page. In the URL bar, I expect it it treat http:/ as http://
(that's just kind of a nice feature). In an HTML page, I think it would be nice
if we made it an option to either use the "broken" behaviour as described below
or treat the URL as http://. Perhaps prompt the user as to what to do or make it
an "advanced tweak".

In either case, this is a candidate for the release notes. 

Comment 11

18 years ago
*** Bug 51971 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
*** Bug 51971 has been marked as a duplicate of this bug. ***
*** Bug 58537 has been marked as a duplicate of this bug. ***
*** Bug 61128 has been marked as a duplicate of this bug. ***
*** Bug 61890 has been marked as a duplicate of this bug. ***
*** Bug 61582 has been marked as a duplicate of this bug. ***
*** Bug 56426 has been marked as a duplicate of this bug. ***
*** Bug 58522 has been marked as a duplicate of this bug. ***
*** Bug 57146 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 65474 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** Bug 68528 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
*** Bug 68977 has been marked as a duplicate of this bug. ***

Comment 23

18 years ago
*** Bug 71441 has been marked as a duplicate of this bug. ***
Adding mostfreq because this comes up so often.

I wonder if we should revisit the decision to handle these links differently
than IE and ns4.x do.  Are we gaining anything for our toeing the line of RFC
2396, especially if no other browser does?

I've begun to wonder if we should have a "full compliance" mode that defaults to
Off in Advanced prefs. (Or a "compatability with other browsers" mode that
defaults to On.)  You could tie quirks to this as well (after all, that's what
quirks.css really is, right?)
Keywords: mostfreq
*** Bug 79369 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
*** Bug 84456 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
*** Bug 84507 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
Today alone there's been three bugs filed about this. Bug 84456, bug 84474, bug
84507. Seems they are normally handed over to evangelism and don't land here.

Comment 29

17 years ago
*** Bug 88356 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
*** Bug 84474 has been marked as a duplicate of this bug. ***

Comment 31

17 years ago
torturing the evang component owner.  At this point bugs filed about 
specific sites which are determined to have the problem here should not be 
resolved as dupes of this bug, but instead be given to the Evangelism component 
for evangelism.

Comment 32

17 years ago
If you look at the comments for BUGID 56426, you'll notice that all Cisco
devices with inbuilt web servers use this syntax of URL.

If this doesn't get changed, no-one with a Cisco device is going to be able to
use Mozilla. (And there are a lot of people with Cisco)

I think having this as a wontfix is a bit like shoting yourself in the foot to
spite your face.

Please can you reconsider ?

Just my 2 pennies worth.

Comment 33

17 years ago
As far as I can tell from the relevant RFCs, the single slash syntax is valid.
(Assignee)

Comment 34

17 years ago
I repeat my comment from 2000-03-24:

From chapter 5.2 of rfc2396:

   3) If the scheme component is defined, indicating that the reference
      starts with a scheme name, then the reference is interpreted as an
      absolute URI and we are done.  Otherwise, the reference URI's
      scheme is inherited from the base URI's scheme component.

      Due to a loophole in prior specifications [RFC1630], some parsers
      allow the scheme name to be present in a relative URI if it is the
      same as the base URI scheme.  Unfortunately, this can conflict
      with the correct parsing of non-hierarchical URI.  For backwards
      compatibility, an implementation may work around such references
      by removing the scheme if it matches that of the base URI and the
      scheme is known to always use the <hier_part> syntax.  The parser
      can then continue with the steps below for the remainder of the
      reference components.  Validating parsers should mark such a
      misformed relative reference as an error.

I think that makes it clear. This kind of relative urls are deprecated, parsers
*may* resolve such urls for backwards compatibility. We deceided to do not back
then, but I will start to dig up my patch for bug 22251 and see how it behaves
today.
(Assignee)

Comment 35

17 years ago
Created attachment 42222 [details] [diff] [review]
the patch from bug 22251 freshed up, anybody want to give it a try?

Comment 36

17 years ago
*** Bug 91180 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
*** Bug 105898 has been marked as a duplicate of this bug. ***

Comment 38

17 years ago
I'd also like to suggest changing this one from WONTFIX.
cnn.com has this problem all over their site.
It's really hard to sell other people on using moz if they can't browse CNN.
(I'm assuming the back bug will get fixed at some point)

Example From:
http://www.cnn.com/2001/US/10/25/inv.investigation.facts/index.html


How will the expansion of law-enforcement powers affect Americans' civil
liberties? <a href="http:/2001/US/09/25/inv.civil.liberties/index.html"
class="text1">Click here for more.</a>

*** Bug 107061 has been marked as a duplicate of this bug. ***

Comment 40

17 years ago
Adding compat keyword. Based on mostfreq bug reports and old browser behavior, I
believe this should be reopened and fixed. Failing to support management of
Cisco routers (Bug 56426) as well as many websites is a problem.

Keywords: compat

Comment 41

17 years ago
I too am hoping it will be reopened.  I have one-way cable modem service.  I 
can't dialup my modem with Mozilla because the built-in web server uses this 
syntax.  It's not just an NT bug either, as I am running Linux and have probs...

Updated

17 years ago
OS: Windows NT → All
Hardware: PC → All
*** Bug 123176 has been marked as a duplicate of this bug. ***

Comment 43

17 years ago
I can't help hoping that http:/ will be handled the way other browsers do.
Unfortunately, this isn't an ideal world, and Moz isn't at the moment in a 
position to dictate standards, especially if they break compatibility for many 
users. If their page/router diag page etc works fine in IE/Netscape, they will 
assume Mozilla is to blame. 

We gain nothing by having an ultimate standards-compliant browser if no-one is 
using it!

Please reconsider at least an option somewhere to allow this behaviour - ie 
IE/netscape compatibility mode, rather than just pointing the finger at the 
webmaster. Our 'Evangelism' department is unlikely to be able to sway every 
site.. I can't blame webmasters for saying 'It's a lot of work, and only 1-2% 
of our users are using Mozilla'.

David

Comment 44

16 years ago
*** Bug 135549 has been marked as a duplicate of this bug. ***

Comment 45

16 years ago
Also from RFC 2396:
   However, a subset of URI do share a common syntax for
   representing hierarchical relationships within the namespace.  This
   "generic URI" syntax consists of a sequence of four main components:

      <scheme>://<authority><path>?<query>

   each of which, except <scheme>, may be absent from a particular URI.
   [...]
      absoluteURI   = scheme ":" ( hier_part | opaque_part )

      hier_part     = ( net_path | abs_path ) [ "?" query ]

      net_path      = "//" authority [ abs_path ]

      abs_path      = "/"  path_segments

This seems to me as requiring the <net_path> to start with two slashes. One
slash after <scheme> ":" indicates <abs_path>. So unless I'm misreading the BNF,
current Mozilla behaviour is incorrect according to RFC 2396.
(Assignee)

Comment 46

16 years ago
But this is also from RFC 2396, indicating it differently:

      If the scheme component is defined, indicating that the reference
      starts with a scheme name, then the reference is interpreted as an
      absolute URI and we are done.  Otherwise, the reference URI's
      scheme is inherited from the base URI's scheme component.

      Due to a loophole in prior specifications [RFC1630], some parsers
      allow the scheme name to be present in a relative URI if it is the
      same as the base URI scheme.  Unfortunately, this can conflict
      with the correct parsing of non-hierarchical URI.  For backwards
      compatibility, an implementation may work around such references
      by removing the scheme if it matches that of the base URI and the
      scheme is known to always use the <hier_part> syntax.  The parser
      can then continue with the steps below for the remainder of the
      reference components.  Validating parsers should mark such a
      misformed relative reference as an error.

According to this a present scheme always indicates an absolute URL.
The above section also suggests a technique for backwards compatibility, since 
links that don't conform exactly to the spec are common.  If a particular type 
of non-conforming link is so common that an RFC goes out of its way to mention 
it, it seems to me like it's worth supporting...
 
(Assignee)

Comment 48

16 years ago
It is implemented, just not in the tree, see the latest patch on bug 40670. It's
a political thing, it was decided to not support this deprecated stuff not even
for backwards compatibility, this decision maybe changed in the future or not.

Comment 49

16 years ago
The paragraph from RFC 2396 that Andreas now quoted for the third time in this
thread is from Section 5.2, which starts by saying: "This section describes an
example algorithm for resolving URI references that might be relative to a given
URI." So, firstly, I think the BNF defines the official syntax and should be the
guiding principle that Mozilla's implementation should try to follow.

Secondly, I think Andreas is misunderstanding what section 5.2 says by "if the
scheme component is defined [...] then the reference is an absolute URI". Look
at my comment above: in Section 3 of the RFC, absolute URI is defined as having
a <hier_part> following the <scheme> and the colon. But the <hier_part> consists
of <net_path> *iff* there are double slashes following the colon. If there is a
single slash, then it's an <abs_path>, and the host name is inherited from base
URI.

I'm sorry, but I don't see what's the political decision to be made here, unless
I'm completely misreading the grammar definition.
(Assignee)

Comment 50

16 years ago
As I understand it an absolute URL does not have a base url only relative urls
do, based on (RFC 2396):

1.4. Hierarchical URI and Relative Forms

   An absolute identifier refers to a resource independent of the
   context in which the identifier is used.  In contrast, a relative
   identifier refers to a resource by describing the difference within a
   hierarchical namespace between the current context and an absolute
   identifier of the resource.

So, its very clear we have a contradiction in RFC 2396. The definitions in the
text do not fit the BNF. This is not the first contradiction, one might remember
the query-problem which was only resolved by an email from one of the authors.
It seems to me the BNF was either not looked upon closely (copy-paste) or it was
made with the backwards compatible implementation in mind.

By definition 1.4 "http:/path" can not be a vaild absolute url, There are three
options: Take it as a malformed absolute URL and try to "fix" it or report a
malformed URL or implement backwards compatibility to take it as a relative url.
Currently we do option one.    

Comment 51

16 years ago
 The issue really is this.  Rather than arguing about BNF or RFCs...  This type of link DOES exist. Regardless of what the BNF or the RFCs say, it is there nonetheless.  It isn't going to go away because we say that it's invalid. CNN.com etc don't care about RFCs, they care that people can view their pages. IE and Netscape + Konqueror resolve these http:/ urls 'correctly' as in that they use it as a relative url.  I am unable to use Mozilla for some applications because of it's handling of URLs. Regardless of the technicalities about who is correct, if IE/Netscape/Konq do it correctly, and Mozilla doesn't, people will blame Mozilla.  Please reconsider the WONTFIX, and consider at least giving an option. Such as :  Support IE/Netscape features   [ ]   This is strictly incorrect, but can help compatibility...   David 
I've r='d the patch in bug 40670. Yes, its deprecated, but the arguments for not
supporting it are very weak, IMHO.

That bug (and bug 22251) should then be marked as dupes of this one.

andreas: Do you want to mail darin for sr of that patch?

reopening for reconsideration.
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
(Assignee)

Comment 53

16 years ago
The patch from bug 40670 is already under consideration. Partys involved are
gagan and evangelism. I havn't heard anything yet. There was a manager decision
to not be backwards compatible back then and there already has been a big amount
of evangelism going into this.

In my opinion it doesn't make sense to sr this stuff until gagan (for
networking) and evangelism both give a green light. cc-ing gagan.

Comment 54

16 years ago
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 139326 has been marked as a duplicate of this bug. ***

Comment 57

16 years ago
*** Bug 139330 has been marked as a duplicate of this bug. ***
*** Bug 140826 has been marked as a duplicate of this bug. ***

Comment 59

16 years ago
*** Bug 141408 has been marked as a duplicate of this bug. ***
*** Bug 145045 has been marked as a duplicate of this bug. ***
*** Bug 149370 has been marked as a duplicate of this bug. ***
*** Bug 150163 has been marked as a duplicate of this bug. ***
*** Bug 152579 has been marked as a duplicate of this bug. ***

Comment 64

16 years ago
*** Bug 151302 has been marked as a duplicate of this bug. ***

Comment 65

16 years ago
RFC2396 says:
   absoluteURI   = scheme ":" ( hier_part | opaque_part )
   hier_part     = ( net_path | abs_path ) [ "?" query ]
   net_path      = "//" authority [ abs_path ]
   abs_path      = "/"  path_segments

"http:/dirone/target" is a valid absolute URI with "http" as the scheme and
"/dirone/target" as the absolute path.
Since the scheme part is present, section 5 of RFC2396 is not relevant and it is
not a relative URI.

See also bug 154195 .
*** Bug 157337 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 67

16 years ago
Created attachment 92767 [details] [diff] [review]
patch freshed up

Since it seems we are doing MARQUEE and document.all in the near future why not
support these deprecated relative urls too. Seems appropiate.
Attachment #42222 - Attachment is obsolete: true
Comment on attachment 92767 [details] [diff] [review]
patch freshed up

Untested, but looks fine to me.

r=bbaetz
Attachment #92767 - Flags: review+
we are not going to do document.all btw :)

This does affect quite a few european topsites and can help topsite compatability.

Who would sr this?
Keywords: topembed
(Assignee)

Comment 70

16 years ago
I'm glad that does not happen!

I asked darin a few days ago for sr= ... no answer yet.
*** Bug 147701 has been marked as a duplicate of this bug. ***
Darin, this patch want's your sr= (I guess you've lost Andreas' mail ;)

Comment 73

16 years ago
Comment on attachment 92767 [details] [diff] [review]
patch freshed up

sr=darin
Attachment #92767 - Flags: superreview+

Comment 74

16 years ago
what gives, why are we all of a sudden compromising on standards?

Comment 75

16 years ago
shear number of duplicates... i don't think we can "fix" the world when it comes
to this bug.  too many websites break.
that tracker has 14 bugs and don't count the dups in here - this should be of
_way_ more use then marquee, maybe the doc.all would. Also this breaks many
pages, which the "typical" current mozilla users (Students, IT people) use.

Comment 77

16 years ago
darin: so will you sign up to get a crummy document.all impl committed to cvs
and to get <img alt="tooltip"> to do what people want instead of what the w3
dictated?

sheEr number of duplicates is not necessarily a good way to set policy.

Comment 78

16 years ago
those things mention aren't in my area of expertise.  i feel confident with the
change andreas has coded up here, but those other ones are much bigger changes
in my opinion, and they should be reviewed by folks working in that area (which
does not include me).  in short, talk to jst :-)

Comment 79

16 years ago
but i don't want those changes :-), just like i don't want this change.

what i'd like is a clear, logical, sane policy to handling mass hysteria (fiat
does not satisfy this or me).  What I see is anything but that.  Mozilla has set
a track record for eventually caving (MPL => GPL, TLS, <style type=text/plain>,
Marquee, and now http:/ - i'm sure there are more, but i think that's enough for
now)
(Assignee)

Comment 80

16 years ago
The problem with this stuff is that there is no definitive answer. The issue
came up in December 1999. I made a first patch in February 2000. It was then
deceided by Warren Harris to not support these deprecated relative urls. I
supported that. Then the bugs came in. By now it is a very impressive list. Part
of it is about hardware, not easy to evangelize!

I and others brought the topic up again, rethinking that previous decision. I
made a change of our policy a long time ago dependend on a word from Evangelism-
and Necko-Managers. No answer yet. So I'm currently thinking about reversing the
approach. Get Review and Super-Review (got it!) and then schedule a checkin in
say about two or three weeks unless there is a veto from Evangelism- and/or
Necko-Managers. Maybe we get an answer this way.

So if you don't want this to happen make yourself a voice.
I also don't want this. We have enough crap in Mozilla. My "Mozilla world" is
destoyed in a few days. 
first marquee and now this and i think they will implement document.all and/or
document.layer in one year.
It's not easy for Mozilla because we have no 90% market share but many people start 
to use mozilla (and also many web developers) we should not go back to NS4.7x days.
We are going back instead of forward :-(

BTW: Thanks Andreas for all your work !

my 0.02€ (but 99% of the developers doesn't care about the community)
Timeless

We are not going against the standars. These type of URLs were described in
RFC1630. And also part of a standar RFC1808: See
http://www.freesoft.org/CIE/RFC/1808/4.htm 

Most browsers support these kind of "URLs". Including NNav 4.x

Then RFC2396 said

      Due to a loophole in prior specifications [RFC1630], some parsers
      allow the scheme name to be present in a relative URI if it is the
      same as the base URI scheme.  Unfortunately, this can conflict
      with the correct parsing of non-hierarchical URI.  For backwards
      compatibility, an implementation may work around such references
      by removing the scheme if it matches that of the base URI and the
      scheme is known to always use the <hier_part> syntax.  The parser
      can then continue with the steps below for the remainder of the
      reference components.  Validating parsers should mark such a
      misformed relative reference as an error.

This last sentence does not apply to Mozilla because Mozilla is not a
"validating parser".

By applying this patch we are implementing the workaround described in RFC2396
for BACKWARD COMPATIBILITY. 

Comment 83

16 years ago
i've actually worked with an employee at cisco to get some of their products
changed. i haven't seen a long list of broken products, but i'm willing to write
letters to hardware vendors about this and speaking http on :1080.

in short i'm opposed to this and will work to improve the world.

can someone please cull out a list of products whose latest versions are known
to be broken?
irs.gov is broken, at least, plus somewhere on my uni's intranet had this at one
stage, IIRC. I've also seen it on various places arround the web.

The point is that this behaviour _is_ part of the standard. True, its
deprecated, and its only there because of a bug in the previous rfve, but its
still there. If and when we start warning for page problems (bug
whatever-it-is), we can add this there. It also will not break any
non-deprecated url, so it _doesn't_ break existing pages.

http-on-1080 is a separate issue, and I disagree with what we're doing there anyway.

Comment 85

16 years ago
this issue should not be compared to other compromises.  by supporting this, i'm
not saying mozilla should cow-tow to broken, inconsistent standards.  instead,
i'm saying let's do backwards compatibility when backwards compatibility makes
sense.   in this case it makes sense since it won't break anybody.  sure we've
tried to evangelize websites to encourage strict conformance with the spec, but
in this case there really isn't much value in being so strict.  for better or
for worse these kinds of relative URLs have become ubiquitous.

if we are to follow the RFCs recommended implementations to the letter then we'd
be a pretty lame browsers, unable to visit most sites.  take our http
implementation for example.  so many compromises are required in order to make
the thing work.  ever heard of "pragma: no-cache" used as a response header? 
sure you have, but guess what?  it's invalid HTTP.  according to the spec it's
not meant to be used as a response header, but ignore it, and you suddenly break
all these websites.  should we evangelize them too?

or how about pipelining?  a webserver says it supports HTTP/1.1, but that
doesn't mean it won't barf on a pipelined request.  but the spec says it should
handle pipelined requests if it says it speaks HTTP/1.1 -- but many many servers
and transparent proxies get this wrong!!  enabling pipelining by default for
mozilla won't force all of those websites to fix or replace their broken
webservers... it'll just make people not want to use mozilla or mozilla-based
products.

frankly, it just seems like the benefits of this patch greatly outweigh the
advantages of the current implementation.

Comment 86

16 years ago
Does the patch in this bug also fix bug 22251, which deals with just the
protocol and colon, with no slash afterwards?
(Assignee)

Comment 87

16 years ago
Yes, of course, it's the whole package ....

Updated

16 years ago
Blocks: 22251
(Assignee)

Comment 88

16 years ago
Answer from aruner:

> As far as I'm concerned, Darin's comment 
> (http://bugzilla.mozilla.org/show_bug.cgi?id=32966#c85) makes sense to me and 
> voices how I stand on this subject.  So I'm not against the patch, but I'd like 
> to CC other people just in case they can think of bad things -- mainly bclary .
If we are not prevented by the standard from fixing this we should. This is a
pain in the ...
(Assignee)

Comment 90

16 years ago
Okay, I think Darins argument is very convincing and evangelism has nothing
against it ... expect a checkin within the next days ...
(Assignee)

Comment 91

16 years ago
fix is in ... now who wants to visit all those dups ...
Status: NEW → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED

Comment 92

16 years ago
*** Bug 107061 has been marked as a duplicate of this bug. ***
the patch seamt to do only half of it's work - http:/path still does NOT work.
only http:file works now.
*** Bug 163352 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 95

16 years ago
It works sort of, the problem is, it works only with links in pages this way. It
currently does not work with redirections, because:

1. The redirection code was not made specifically with relative urls in mind.
2. The code that is used does it's own checking for relative urls, which it
shouldn't, it should leave that to ::Resolve.

I filed bug 163225 on the problem and attached a patch.

Updated

16 years ago
Alias: relative

Updated

16 years ago
Alias: relative → relative-http
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0.1
Comment on attachment 92767 [details] [diff] [review]
patch freshed up

a=rjesup@wgate.com for 1.0 branch

Change mozilla1.0.2+ to fixed1.0.2 when checked in
Attachment #92767 - Flags: approval+

Updated

16 years ago
Keywords: mozilla1.0.1 → mozilla1.0.2+
Target Milestone: --- → mozilla1.0.2
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0.2+ → fixed1.0.2

Updated

16 years ago
Keywords: testcase
QA Contact: ckritzer → benc
Summary: http:/ (one slash) treated as http:// rather than / → URL: http:/ (one slash) treated as http:// rather than /

Comment 97

16 years ago
Please verify the bug. Once verified, change the keyword fixed1.0.2 to
verified1.0.2 

Comment 98

16 years ago
I'll handle the dupes.

Comment 99

16 years ago
VERIFIED:
This did not work in 1.1, but as I understand it, it shouldn't because it wasn't
checked into branch 1.1

Mozilla 1.2a, allplats
Status: RESOLVED → VERIFIED

Comment 100

16 years ago
VERIFIED/BRANCH:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20020924
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20020924
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20020924
Keywords: fixed1.0.2 → verified1.0.2
*** Bug 190275 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.