Closed
Bug 32966
(relative-http)
Opened 25 years ago
Closed 22 years ago
URL: http:/ (one slash) treated as http:// rather than /
Categories
(Core :: Networking, defect, P3)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla1.0.2
People
(Reporter: jkane, Assigned: andreas.otte)
References
()
Details
(Keywords: compat, testcase, topembed)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
bbaetz
:
review+
darin.moz
:
superreview+
jesup
:
approval+
|
Details | Diff | Splinter Review |
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 2•25 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•25 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•25 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•25 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
Assignee | ||
Comment 7•25 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
Closed: 25 years ago
Resolution: --- → WONTFIX
Comment 10•24 years ago
|
||
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•24 years ago
|
||
*** Bug 51971 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 51971 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
*** Bug 58537 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 61128 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
*** Bug 61890 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
*** Bug 61582 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
*** Bug 56426 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
*** Bug 58522 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
*** Bug 57146 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
*** Bug 65474 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
*** Bug 68528 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 68977 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
*** Bug 71441 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
*** Bug 79369 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
*** Bug 84456 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
*** Bug 84507 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
*** Bug 88356 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
*** Bug 84474 has been marked as a duplicate of this bug. ***
Comment 31•23 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•23 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•23 years ago
|
||
As far as I can tell from the relevant RFCs, the single slash syntax is valid.
Assignee | ||
Comment 34•23 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•23 years ago
|
||
Comment 36•23 years ago
|
||
*** Bug 91180 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
*** Bug 105898 has been marked as a duplicate of this bug. ***
Comment 38•23 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>
Comment 39•23 years ago
|
||
*** Bug 107061 has been marked as a duplicate of this bug. ***
Comment 40•23 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•23 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•23 years ago
|
OS: Windows NT → All
Hardware: PC → All
Comment 42•23 years ago
|
||
*** Bug 123176 has been marked as a duplicate of this bug. ***
Comment 43•23 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•23 years ago
|
||
*** Bug 135549 has been marked as a duplicate of this bug. ***
Comment 45•23 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•23 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.
Comment 47•23 years ago
|
||
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•23 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•23 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•23 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•23 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
Comment 52•23 years ago
|
||
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•23 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•23 years ago
|
||
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 55•23 years ago
|
||
LIST OF EVANGELISM SITES THAT DEPENDS ON THIS:
----------------------------------------------
Bugzilla US and international
(CISCO HTTP DEVICES) - http://bugzilla.mozilla.org/show_bug.cgi?id=56426
(CLARENCE.COM) - http://bugzilla.mozilla.org/show_bug.cgi?id=61582
(GDB.ORG) - http://bugzilla.mozilla.org/show_bug.cgi?id=68528
(http://www.econ.upenn.edu/) - http://bugzilla.mozilla.org/show_bug.cgi?id=91364
(http://homepages.feis.herts.ac.uk/~2com0001/)-
http://bugzilla.mozilla.org/show_bug.cgi?id=107061
(Swedish goverment) - http://bugzilla.mozilla.org/show_bug.cgi?id=125010
(msu.edu) - http://bugzilla.mozilla.org/show_bug.cgi?id=40670
(ARGENTINA Associated Press -> http://worldphoto.ap.org/)
Comment 56•23 years ago
|
||
*** Bug 139326 has been marked as a duplicate of this bug. ***
Comment 57•23 years ago
|
||
*** Bug 139330 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
*** Bug 140826 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
*** Bug 141408 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
*** Bug 145045 has been marked as a duplicate of this bug. ***
Comment 61•23 years ago
|
||
*** Bug 149370 has been marked as a duplicate of this bug. ***
Comment 62•22 years ago
|
||
*** Bug 150163 has been marked as a duplicate of this bug. ***
Comment 63•22 years ago
|
||
*** Bug 152579 has been marked as a duplicate of this bug. ***
Comment 64•22 years ago
|
||
*** Bug 151302 has been marked as a duplicate of this bug. ***
Comment 65•22 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 .
Comment 66•22 years ago
|
||
*** Bug 157337 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 67•22 years ago
|
||
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 68•22 years ago
|
||
Comment on attachment 92767 [details] [diff] [review]
patch freshed up
Untested, but looks fine to me.
r=bbaetz
Attachment #92767 -
Flags: review+
Comment 69•22 years ago
|
||
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•22 years ago
|
||
I'm glad that does not happen!
I asked darin a few days ago for sr= ... no answer yet.
Comment 71•22 years ago
|
||
*** Bug 147701 has been marked as a duplicate of this bug. ***
Comment 72•22 years ago
|
||
Darin, this patch want's your sr= (I guess you've lost Andreas' mail ;)
Comment 73•22 years ago
|
||
Comment on attachment 92767 [details] [diff] [review]
patch freshed up
sr=darin
Attachment #92767 -
Flags: superreview+
Comment 74•22 years ago
|
||
what gives, why are we all of a sudden compromising on standards?
Comment 75•22 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.
Comment 76•22 years ago
|
||
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•22 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•22 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•22 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•22 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.
Comment 81•22 years ago
|
||
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)
Comment 82•22 years ago
|
||
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•22 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?
Comment 84•22 years ago
|
||
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•22 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•22 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•22 years ago
|
||
Yes, of course, it's the whole package ....
Assignee | ||
Comment 88•22 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 .
Comment 89•22 years ago
|
||
If we are not prevented by the standard from fixing this we should. This is a
pain in the ...
Assignee | ||
Comment 90•22 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•22 years ago
|
||
fix is in ... now who wants to visit all those dups ...
Status: NEW → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → FIXED
Comment 92•22 years ago
|
||
*** Bug 107061 has been marked as a duplicate of this bug. ***
Comment 93•22 years ago
|
||
the patch seamt to do only half of it's work - http:/path still does NOT work.
only http:file works now.
Comment 94•22 years ago
|
||
*** Bug 163352 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 95•22 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.
Assignee | ||
Updated•22 years ago
|
Keywords: mozilla1.0.1
Comment 96•22 years ago
|
||
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•22 years ago
|
Keywords: mozilla1.0.1 → mozilla1.0.2+
Target Milestone: --- → mozilla1.0.2
Assignee | ||
Updated•22 years ago
|
Keywords: mozilla1.0.2+ → fixed1.0.2
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•22 years ago
|
||
Please verify the bug. Once verified, change the keyword fixed1.0.2 to
verified1.0.2
Comment 99•22 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•22 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
Comment 101•22 years ago
|
||
*** 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.
Description
•