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




14 years ago
14 years ago


(Reporter: u130342, Assigned: Darin Fisher)


Windows XP

Firefox Tracking Flags

(Not tracked)




14 years ago
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.

<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);
    var expr = /^@(\d+)(.*)$/;
      url=RegExp.$2; skip=RegExp.$1;
      // alert(url);

      document.writeln('waiting '+skip+' msec<br>loading...<br><a
      window.setTimeout("window.location.replace(unescape('"+ url+"'));", skip);
    } else

Reproducible: Always
Steps to Reproduce:
see details

Expected Results:  
get the bookmark part in window.location.hash and the query part in
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

In other words, when you were doing:


you should have been doing:

Last Resolved: 14 years ago
Resolution: --- → INVALID

Comment 3

14 years ago
V/dupe: you can see some related examples about the trickiness of the URL
reserved characters and their order in:


Summary: window.location.search not filled when bookmark and query is given → window.location.search vs. "#" (anchor)


14 years ago
Summary: window.location.search vs. "#" (anchor) → URL: window.location.search vs. window.location.hash

Comment 4

14 years ago
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...

Comment 6

14 years ago
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....

Comment 8

14 years ago
I would say ? is possible in fragment only in %3f encoding if the order #..? is
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.