Closed Bug 90439 Opened 23 years ago Closed 23 years ago

relative queries from cgi broken

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: schoeller, Assigned: bbaetz)

References

(
URL
)

Details

(Keywords: compat, relnote, Whiteboard: WONTFIX ? -- non standards compliant (py8ieh:find "" bug))

Attachments

(4 files)

Okay here is the patch, hope I get my own stuff back together ...
1.36 KB, patch
Details | Diff | Splinter Review
patch for the "" thing, if we ever decide what do do ...
818 bytes, patch
Details | Diff | Splinter Review
patch to bring back only the query handling of pre 0.9.2
1.05 KB, patch
Details | Diff | Splinter Review
fixed indention of patch
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.
Keywords: qawanted
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?
Assignee: neeti → bbaetz
Keywords: qawanted → compat
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.
Keywords: relnote
Okay, since Stuart has no objections, I will put mine to rest. Stuart can you
provide the patch to revert or just back the change for bug 78206 out? My
nsStdURL.cpp contains currently other changes (related to bug 40670) which I
don't want to put into any danger.
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.
r=bbaetz
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 ian@hixie.ch.
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-990323123038Z-32643@odin.cromwellm
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.
sr=darin
fix checked in
Status: NEW → RESOLVED
Closed: 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: