Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This isn't possible as clients don't send the "anchor part" to the server</p> <p>As an example, here's the exact request that Chrome generated after submitting <code>http://example.com/#foobar</code> (recorded using Wireshark):</p> <pre><code>GET / HTTP/1.1 Host: example.com Connection: keep-alive User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.3 (KHTML, like Gecko) Chrome/4.0.223.11 Safari/532.3 Cache-Control: max-age=0 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 If-None-Match: "b300b4-1b6-4059a80bfd280" If-Modified-Since: Tue, 15 Nov 2005 13:24:10 GMT </code></pre> <p>See, no #foobar. So there's no way a server application can read it.</p> <p>You could do some JavaScript magic to store the anchor in a cookie or in a hidden input field or whatever voodoo you're into. But it won't ever work for requests that don't originate from your own sites. It's simpler to make whatever you need on the server part of the query string and use the anchor only for JavaScript-only tasks - or use it to navigate inside a simple HTML document - but that's so 90s ;).</p> <p>Here's the important part from the mentioned RFC 1808:</p> <blockquote> <p>Note that the fragment identifier (and the "#" that precedes it) is not considered part of the URL. However, since it is commonly used within the same string context as a URL, a parser must be able to recognize the fragment when it is present and set it aside as part of the parsing process.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload