URI #fragment sent to server



  • Am I going crazy? I always assumed that anything after the hash symbol in a URL is not sent to the server, but apparently is blocking it is causing issues?

    I can't find any evidence in my own logs but apparently production logs have them coming into the server. Googling suggests no browser send it so WTF!?



  • @Zemm said:

    but apparently is blocking it is causing issues?

    What kind of issues? While it seems actual browsers do strip the #tags, if a #tag at the end makes your server go up in smoke, then you'll want to fix that on your end. Otherwise you're opening yourself to any jackass with curl.



  • check the user agents, maybe there are bots or other http clientes sending it


  • Fake News

    Throw some query parameters into the mix for extra fun time with certain URI matchers:

    http://zombo.com/sound;high-quality



  • @Maciejasjmj said:

    What kind of issues?

    There's a tracking script which uses #something=code and apparently the sysadmins had to make a change to the load-balancer to make it work, even though it still doesn't. He send through a part of the log to "prove" that fragments get sent. Maybe he is logging the referrer or something...


  • BINNED

    No, those will never reach the server.

    Can you access the page in question? Poke around with inspector and you'll probably find some JavaScript attached to onhashchange event or similar.

    As for the logs, whatever his logs show that's something about how he logs stuff, or the # character was actually sent as %23 and then turned back into # when he read them / they were written?



  • It's never supposed to be sent to the server as per HTTP spec.



  • Is this the same for Ajax?

    Or maybe the # is getting encoded, the server decodes it an bam!



  • Still a case of :doing_it_wrong:



  • Probably Twitter is doing something like this, but I'm sure it's on POST requests.



  • @Onyx said:

    Poke around with inspector and you'll probably find some JavaScript attached to onhashchange event or similar.

    I couldn't get Chrome to do it. That isn't to say that some other browser does something dodgy.

    @Onyx said:

    or the # character was actually sent as %23 and then turned back into # when he read them / they were written?

    I thought of that but my logs on dev boxes have encoded %23 in them. But there are so many layers of load balancing between the browser and web servers who TF knows where those logs even came from! I don't have access to production apache access logs (but I do the error log) and no access to any of the load balancers.

    @Arantor said:

    It's never supposed to be sent to the server as per HTTP spec.

    Exactly my assertion, but there was still his argument.

    Anyway, this tracking code thing is so unreliable. JS creates a hidden iframe which sets a cookie on the tracker servers, then the "success" page does the same with a different iframe URL for linking referrals. One of our small clients have apparently referred over half the signups! No idea how that happens. In our testing results have varied dramatically from not sending tracking to being correct to applying to the wrong tracking account.


  • BINNED

    @Eldelshell said:

    Probably Twitter is doing something like this, but I'm sure it's on POST requests.

    I'm not going to claim I know 100% what they are doing, but I can speculate since I did something similar: before the history API using hashes was a semi-decent way to get shareable URLs and still keep all the things load dynamically.

    What you'd do is make all links point to, for example /#!/controller/method (assuming serverside MVC in this example). Putting that in the browser will initially try to load whatever loads when accessing /, but you can of course preempt that, get the hash fragment and inject content as needed. Clicking on that link would trigger a hashchange event where you could, once again, read the fragment and load whatever you needed.

    The main problem with this was always the fact that pasting the URL into a browser where JS was disabled/not available the routing would break, since the fragment never reaches the server. These days, most people will use the history API (for example, Discourse, hence the history spamming) which enables you to push a new URL, without the fragment, to the browser but still have it not load it from the server and do all the routing in JS. And of course, if your routing is set up properly, it even works on pasting and/or clicking in a browser without JS support.

    TL;DR: Twitter uses it for GET request to get full dynamic navigation mostly working but without the history API.


Log in to reply