Closed Bug 90439 Opened 21 years ago Closed 20 years ago
relative queries from cgi broken
1.36 KB, patch
|Details | Diff | Splinter Review|
818 bytes, patch
|Details | Diff | Splinter Review|
1.05 KB, patch
|Details | Diff | Splinter Review|
1.05 KB, patch
|Details | Diff | Splinter Review|
This appears to be related to the fix for bug #78206. With 0.9.2, cgis that generate new queries to themselves with href="?foo" are broken. This is inconsistent with the behavior in IE and in earlier Mozilla versions. IE5 and earlier versions of Mozilla appear to implement the relative URL algorithm for queries per rfc1808. The new version appears to implement rfc2396. I may be off base, but since the HTML 4.0 and 4.01 specs refer to rfc1808 shouldn't you implement the rfc1808 algorithm? The change to the new algorithm should only be applied if the spec changes and then only if the DTD points to the new version of HTML.
i seem to remember someone explaining why we do what we do...
Assignee: asa → radha
Component: Browser-General → History: Session
QA Contact: doronr → claudius
Over to networking. ccin stuart, doug, bradley
Assignee: radha → neeti
Status: UNCONFIRMED → NEW
Component: History: Session → Networking
Ever confirmed: true
QA Contact: claudius → benc
cing andreas The new behaviour was presented as identical to how ie and 4.x do it, which is why it was changed. The current behaviour matches netscape 4.77 on unix (the page is unreadable though). Is ie different?
+qawanted: There are several bugs on issues of this nature. I don't pretend to be the expert here, so I'd like to defer to someone else's analysis.
I was the filer and advocate of bug 78206. I've been using href="?foo" for several months on my site and relying on it to provide correct navigation if the user has cookies turned off. Old versions of mozilla were the only browsers that this broke on. 4.x, all versions of IE that I've tested, and rfc2396 agree on this behavior. Can you identify a version of IE that behaves differently? I think it's reasonable to obey rfc2396 since that draft obsoletes rfc1808. I suppose, if different browsers already behave differently wrt this, the correct thing for both of us to do would be to recode our sites not to rely on this feature. But I'd much rather stick with the backward (4.x) compatible behavior we have now.
I also agree the we should go with 2396, but I have to admit that the behaviour of 1808 in this cases makes more sense to me. I just don't see why a relative url that only contains a query component should affect the filename component of the url. But 2396 obsoletes 1808, may I like it or not in this case.
Andreas: Here's the logic that caused me to try this in the first place. It's always made sense to me. Suppose we're at http://foo/bar/baz.asp. Then: <a href="aaa"> ==> http://foo/bar/aaa <a href="aa"> ==> http://foo/bar/aa <a href="a"> ==> http://foo/bar/a <a href=""> ==> http://foo/bar/ <== example 1 <a href="aaa?b"> ==> http://foo/bar/aaa?b <a href="aa?b"> ==> http://foo/bar/aa?b <a href="a?b"> ==> http://foo/bar/a?b <a href="?b"> ==> http://foo/bar/?b <== example 2 I do understand the logic which suggests *not* working this way. But I've tested the first example with every browser under the sun (IE 3,4,5.0,5.5; NS3,4.0,4.5-7; Mozilla, lynx, konqueror) and never seen it fail. And if the first example (href="") works, logically the second example should work too (otherwise how can you add a querystring to the first example?).
The logic that is described by Stuart which reduces the filename down until there is nothing left could also be applied to the id specifier. Thus "#foo" should apply to the directory containing the referring file. But it doesn't. It seems that it is obvious to everone that the relative reference to an id must be the same file, not the directory. Otherwise renaming the file must require editing the file to change the references. A similar kind of problem arises for queries. Since a query will frequently point to some other page generated from a different query to the same application, the same relative link need exists. If you follow the current implementation there is no way for query result to refer back to itself without being explicit about the script name. As far as how can I get a query string to the directory if I need it... "./?b" will yield the result that Stuart is looking for. Admittedly this does not progress neatly from "a?b" to "?b" the way that example 2 does. But it leaves the option open for relative queries back to the same script. As far as the statement that the new RFC should be followed. An argument can be made that if the W3C wanted the definition of HTML 4.0 and 4.1 to vary with the RFCs then they would have worded the HTML spec differently. For example wording the spec to refer to "RFC1808 or any superceding RFC". They didn't do this. I would take that to indicate that they wanted the behavior of compliant HTML 4.0 and 4.1 to remain constant even if the RFCs referenced were superceded. Thus, if the browser is to implement HTML 4.0 and 4.1 according to the standard, it should implement 1808. Finally, I have tested the URL listed above with IE5.5 on Windows NT 4.0, Windows98 and Windows 2000 and all of them exhibit the behavior that Mozilla had prior to 0.9.2. The query string causes the empty path to be the same file and not the directory containing the file. Of course, to be honest I don't like using the argument that IE behavior should be followed. I personally prefer that standards and sensibility of behavior should come ahead of comparison with other products in the field.
Seems to me current browsers do follow Stuarts logic with example one but not with example two. Back on the drawingboard I think. http://foo/bar/baz.asp: <a href="aaa"> ==> http://foo/bar/aaa <a href="aa"> ==> http://foo/bar/aa <a href="a"> ==> http://foo/bar/a <a href=""> ==> http://foo/bar/ okay, but <a href="aaa?b"> ==> http://foo/bar/aaa?b <a href="aa?b"> ==> http://foo/bar/aa?b <a href="a?b"> ==> http://foo/bar/a?b <a href="?b"> ==> http://foo/bar/baz.asp?b instead. As a little sidenote we have to figure out a way to add a querystring to the first example: Maybe <a href="./?b">, I will do some tests.
Andreas: Agreed, but only if you're careful about the definition of "current browsers". 4.x follows my logic for both cases, and I know that I tested at least one version of IE for the second case too (I think it was 4.0 but it might have been 5.0). So "current browsers" would have to be restricted to "recent versions of IE and previous mozillas". My worry about using "./" is that I'd expect many browsers to give me http://foo/bar/./?b - which, while technically correct, would look funny and ugly.
Okay, I've put back in locally the code that was removed with bug 78206 to check this out. Works fine and ./?a works too. I would not worry about /./?a, if that happens it would be a real bug and I haven't seen it on any browser. If Benjamin Chuang is correct and there are now some bugs about this (which?) we might have broken something with fixing bug 78206, at least IE compatibility. But that should not be our concern, standards compatibility should be, and of course web compatibility in general. There seems to be more testing in order to find out what other browsers do in this case. I can confirm that NS4.76 on linux works like Stuart said as does Konquerer 1.9.8. I have set up http://www.begriffslogik.de/bug90439.html to check against, just compare the url in the statusline with the displayed url while hovering over it. What does IE do here? Please post the results to this bug with browser version and OS. With conflicting rfcs it is a no win scenario ... something will get broken ...
IE 5.0 on win 98: let the filename as it is NS 4.7 on win 98: kills the filename Any older stuff out there ?
Ooh. I have to apologize: I could have sworn that I had tested this behavior on IE4.0, but I just tested it again to be sure and it turns out IE4.0 has the same behavior as IE5 (for the case with the querystring - the empty href does kill the filename). Probably my IE tester had cookies turned on for the site (against my advice - long story) so there was nothing in his querystring. It looks like historically the behavior has always been for NS to kill the filename and IE not to. So I guess I'll switch my code over to using ./ and we can revert to the old behavior. (However, it still seems that the standards specify killing the filename, so if we do switch, we're doing it for IE compatibility, not standards compliance...)
And that is why I now don't think we should revert to the old behaviour easily. Has anyone an older communicator available to find out if Netscape changed the behaviour and when?
Netscape 3.04 (windows) behaved the same way Netscape 4.x does. I wouldn't be surprised if this behavior has never changed at all in either browser.
*** Bug 91868 has been marked as a duplicate of this bug. ***
The standards are confusing, because there are two of them which are mutually exclusive. Since we can't comply with both standards at the same time, I suggest that we revert the fix for bug 78206, for the sake of compatability with ie. I'll do this sometime this week, unless someone can convince me otherwise. Taking bug. adding compat keyword, although since we're still arguing over what is the correct solution its not really appropriate. There are arguments on both sides, but since there isn't a working group (AFAIK) to look at this, we really just have to pick one solution. Comments?
What do we weight higher? Compatibility with previous Netscape 4.x releases and following a rfc that is current state or compatibility with IE and following an rfc that is obsolete? I personally like the way it is done in rfc 1808 more than it is done in rfc 2396, but that can not be an option. Maybe it is possible to get some opinion from the authors of the rfc's or from W3C. Until then I would stay with the current status.
How about making any URL like this pop up a dialog box saying "URLs like this are interpreted differently in every browser - I don't know what the page author intended"? ;) (yes, I'm kidding, hence the ;) ) As the original advocate of bug 78206, I don't care if that "fix" gets reverted - I'm going to have to change my site anyway for correct behavior under IE (nobody seems to have noticed the bug - I guess all IE users allow cookies ;) ). Since I seem to be the only person in the entire world relying on this behavior, it's probably safe to revert it :) In my personal opinion, IE compatibility on a trivial matter like this isn't a big deal - we might as well just do it. It's not a standard that's worth "taking a stand" over in the way that document.getElementById vs document.all is. In today's internet, NOBODY is going to be writing code that *only* works on Netscape 4.x (and this isn't really something that can be browser-detectioned away). So we can either leave *both* behaviors effectively unavailable, or go with IE compatibility so that web developers at least have a "de-facto" standard they can rely on, even if it's not the "de jure" standard.
Workability first. This isn't the type of standards debate that is going to win us anything by being "right". When I try to explain this to someone, half the time I think side "a" is correct, the other half I think side "b" is correct. If the "right" way isn't coherent enough where I can explain it verbally, we should do what others do. Yes, I volunteer to document and relnote if we fix this.
I don't have a copy of the source tree to hand right now and LXR isn't doing what I want it to (the one page I can find that will show the checkin doesn't provide a backout option; the page that provides backout options only goes back a month). But I can tell you that the appropriate revisions to pass to cvs diff would be revisions 1.78 (before 78206 fix) and 1.79 (after 78206 fix). Presumably cvs diff, with approriate -r options, would give the diff we need. (It's not that I *like* the pre-78206 behavior... but there's no use in having a "better" behavior if it's not supported in the browsers that are actually out there. And I don't think this is a "standards" battle worth fighting...)
I'll talk to darin about it tomorrow.
I think this bug should be WONTFIXed. I made a testcase for this issue: http://www.hixie.ch/tests/adhoc/uri/001.html ...and tested 7 different recently released browsers. Three of the seven did this the RFC1808 way, and four did this the RFC2396 way. This means that authors cannot rely on either behaviour, and therefore we might as well do it right. (The results are shown on the page.) BTW, is there a bug open on our handling of an empty ("") URI? We currently do it incorrectly as I understand it. Please send any corrections about this page to email@example.com.
Whiteboard: WONTFIX ? -- non standards compliant
Hixie: Yes, we do href="" "incorrectly", but only if you define incorrectly as "the same way every browser has done it since the beginning of time". I've tested netscape 3.0x, 4.0x, 4.5x, IE 3.x, IE4.x, IE5.0, IE5.5, Konqueror, and Lynx for href="" and every one of them does it the same way we do. One of my sites relies on this behavior, and I doubt I'm the only one. It's not quite what the standards specify, but it's certainly a de-facto standard. If there was such a bug, I'd argue strongly for it to be WONTFIXed. I don't care whether this bug is WONTFIXed or not; the reason I lean towards IE compatibility is just that so many authors these days test on IE only - these authors *will* rely on that behavior, regardless of whether other browsers act different.
For the "" issue, note that of the following current browsers, only one does it incorrectly (referring to the directory instead of the current page): Escape4.7, iCab2.51-pre, Lynx2.8.3-pre, Opera5, MacIE5, WinIE6-pre Not quite "the same way every browser has done it since the beginning of time". See: http://www.hixie.ch/tests/adhoc/uri/001.html
Whiteboard: WONTFIX ? -- non standards compliant → WONTFIX ? -- non standards compliant (py8ieh:find "" bug)
Interesting results. I have definitely tested this on some version of lynx and seen the "./" behavior; I've also seen it on Konqueror. And you cunningly failed to mention that the "one other browser" also just happens to be the one with ~90% market share ;) Also the fact that about 8 of the remaining 10% is NN4.x which behaves the same way for href="", even though it's not a "current" browser. I'd also be interested to see the results for all these browsers if you give them "./" as a URI - how many of them actually show the ".", if any? That is, from http://foo/bar/baz.asp given <a href="./">, does the browser produce "http://foo/bar/" or "http://foo/bar/./"? I'd be much happier accepting a change to the behavior if I knew I could rely on "./" doing the right thing across at least the majority of browsers.
Is this going into the developer releasenotes?
This is a snippet from a standards complinance discussion in netscape.public.mozilla.netlib: Despite the fact that RFC 2396 conflicts with RFC 1808, that's not the intention. See Roy's comments below ... ========================== From: Roy T. Fielding Sent: 26 March 1999 1:45 am To: Miles Sabin Subject: Re: Typo in RFC 2396? You are right, that is an error. Not exactly a typo though -- that was the common result prior to IE4 and Netscape 4.5 -- but the algorithm was restored to 1808-style late in the process. ....Roy In message <c=US%a=_%p=Cromwell_Media%l=ODIN-990323123038Zfirstname.lastname@example.org edia.co.uk>, Miles Sabin writes: >Hi, > >I've been working through the relative URI resolution >mechanism in RFC 2396, and I've spotted something which >seems a little odd. The example resolution on p.29 for, > > ?y > >from, > > http://a/b/c/d;p?q > >is given as, > > http://a/b/c/?y > >but as far as I can make out, the resolution algorithm >suggests the result ought to be, > > http://a/b/c/d;p?y > >which is the result that was given in RFC 1808. It's >also the result that both Netscape 4 and IE 4 deliver. > >Given that this would be an observable change in >behaviour between the two RFCs, I'm a little surprised >that it wasn't flagged up as such if the change really >was intended ... > >Strangely enough, Sun's badly broken java.net.URL class >_does_ give the result specified in 2396, which makes me >suspect that something must be wrong [;-)] > >Cheers, > > >Miles > It seems at least the query handling documented in RFC 2396 is wrong, the real intention of the authors was another, more like in RFC 1808. I think we should at least change the query handling back to the pre 0.9.2 behaviour.
I could not find a bug for the "" thing, so I opened bug 94849.
You have some wacky indentation. r=bbaetz with that fixed.
fix checked in
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 96071 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.