Closed Bug 241504 Opened 20 years ago Closed 20 years ago

URL: window.location.search vs. window.location.hash

Categories

(Core :: Networking, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

VERIFIED INVALID

People

(Reporter: u130342, Assigned: darin.moz)

Details

User-Agent:       Mozilla compatible
Build Identifier: Firefox 0.8, Mozilla/5.0 (Windows)

At the end you find reload.htm which redirects to another page.
Normally I call it like this
a)  http://localhost/cams/reload.htm#?http%3A//localhost/test.html
but i tried it also with
b)  http://localhost/cams/reload.htm#abookmark?http%3A//localhost/test.html

I expected to have in the first case 
  window.location.search = "?http%3A//localhost/test.html" // or without ?
  window.location.hash = "#"
and in the second case
  window.location.search = "?http%3A//localhost/test.html"
  window.location.hash = "#abookmark"

but what I'm getting is
  window.location.search = ""
  window.location.hash = "#abookmark?http%3A//localhost/test.html"

In words the query string is appended to the bookmark if any bookmark is present.

I can reproduce it in Mozilla 1.6 as well.
It workes for the old Netscape Navigator and IE6.

reload.htm:
<html>
<head>
<title>...</title>
</head>
<body bgcolor="#333333" text="white" link="#FFFF99" vlink="#FFFF99" alink="#FFFF99">
<font size=1>
<!-- reload.htm?[~{delay}]{escaped_url} -->
<SCRIPT language=JavaScript>
function _start()
{
  var  url=window.location.search;
  var skip=url.indexOf('?');
  if(skip>=0) url=url.substring(skip+1,url.length);
  // alert(window.location);
  if(url!="")
  {
    var expr = /^@(\d+)(.*)$/;
    if(expr.exec(url))
    {
      url=RegExp.$2; skip=RegExp.$1;
      // alert(url);

      document.writeln('waiting '+skip+' msec<br>loading...<br><a
href="'+unescape(url)+'">'+unescape(url)+'</a><br>');
      window.setTimeout("window.location.replace(unescape('"+ url+"'));", skip);
    } else
    {
      document.writeln('loading...<br><a
href="'+unescape(url)+'">'+unescape(url)+'</a><br>');
      window.location.replace(unescape(url));
    }
  }
}
_start();
</SCRIPT>
</font>
</body>
</html>

Reproducible: Always
Steps to Reproduce:
see details


Expected Results:  
get the bookmark part in window.location.hash and the query part in
window.location.search.
This has nothing to do with JS engine.
Assignee: general → darin
Component: JavaScript Engine → Networking
QA Contact: pschwartau → benc
Further, this is invalid.  Everything after the '#' is part of the fragment
identifier.  If both a fragment identifier and a query are present, the query
must come first.  The fragment identifier is not even part of the URI proper,
while the query most definitely is.  See RFC 2396
<http://web.mit.edu/rfc/rfc2396.txt>.

In other words, when you were doing:

  http://localhost/cams/reload.htm#abookmark?http%3A//localhost/test.html

you should have been doing:

  http://localhost/cams/reload.htm?http%3A//localhost/test.html#abookmark
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
V/dupe: you can see some related examples about the trickiness of the URL
reserved characters and their order in:

http://www.ics.uci.edu/%7Efielding/url/test1.html




Status: RESOLVED → VERIFIED
Summary: window.location.search not filled when bookmark and query is given → window.location.search vs. "#" (anchor)
Summary: window.location.search vs. "#" (anchor) → URL: window.location.search vs. window.location.hash
OK, thx for info and sorry for posting it, but I remember that I had to use a
"#?" construct to get the script to work on a browser. So after lots of
experimenting i assumed #? is the correct order. 
I agree with you that the rfc states bookmark after query.
Maybe you can think of being tolarant to that misordering ..  but i will change
my script.
I'm surprised not facing that pb because i'm calling .htm with #? since 2 years
or more.
> Maybe you can think of being tolarant to that misordering 

How, exactly?  You can have a '?' char in a fragment identifier...
bz: communicator would allow "?" after a fragment to be a query. 

This was wrong, but we actually had netscape.com pages for Netscape 6 that were
supposed to use links like this, which were broken b/c Netscape 6 parsed them
correctly and went to the wrong anchor on the page. (someone at AOL was probably
writing pages for the site using Communicator for viewing).
> bz: communicator would allow "?" after a fragment to be a query. 

Yes, I realize that.  It had a lot of other bugs too....
I would say ? is possible in fragment only in %3f encoding if the order #..? is
used.
I think its very unlikely to have an '?' in a query
maybe #a?b#c expands to fragment #a and query #a?b#c.
I would apply these regular expressions (it's simplified of course), depending
on the first character:
\?[^#]*(#.*)?
#[^\?]*(\?.*)?

in other words:
- when fragment comes first, it may not contain a ? which starts a query (the
query may contain unescaped #).
- when query comes first, it may not contain a # which starts the fragment (the
fragment may contain unescaped ?)

I wonder wether #text? is used in the field or wether it's just "#?" without a
real fragment. 

In my personal opinion the rfc aren't good at this point of definition, because
# is not a reserved character. If it were, we wouldn't have that problem.

How's about setting 
 window.location.search = "?http%3A//localhost/test.html"
 window.location.hash = "#abookmark?http%3A//localhost/test.html"
for http://localhost/cams/reload.htm#abookmark?http%3A//localhost/test.html
I don't like it much but maybe thats a possible way.
But in this case when focusing the fragment it would be intelligent to jump to 
the fragment "#abookmark?http%3A//localhost/test.html" if present, and if not
present jump to "#abookmark".
> because # is not a reserved character.

Sure it is.  See section 2.4.3 of the RFC.  An unescaped '#' is allowed in a URI
ONLY if it marks the beginning of the fragment identifier.
Unless you mean "reserved" in the sense the RFC uses it.  '#' is stronger than
that -- it's a "delim", which means that it's not allowed as part of URIs at all
(technically the fragment identifier is not part of the URI proper), unlike '?'
which is allowed to delimit the query.  So once you have hit a '#' you know you
have reached the end of the URI and the rest of what follows is part of the
fragment identifier, not part of the URI itself.
You need to log in before you can comment on or make changes to this bug.