Closed
Bug 241504
Opened 20 years ago
Closed 20 years ago
URL: window.location.search vs. window.location.hash
Categories
(Core :: Networking, defect)
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.
Comment 1•20 years ago
|
||
This has nothing to do with JS engine.
Assignee: general → darin
Component: JavaScript Engine → Networking
QA Contact: pschwartau → benc
Comment 2•20 years ago
|
||
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.
Comment 5•20 years ago
|
||
> 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).
Comment 7•20 years ago
|
||
> 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".
Comment 9•20 years ago
|
||
> 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.
Comment 10•20 years ago
|
||
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.
Description
•