Hacker News Reader

Comment by denisinvader | Hacker News Reader

hash part of url only available in the browser, as far as I know, server doesn’t have access to # value

Typos and URL mangles are common though, and I'd still have no way to confirm if it got logged in that case. It's out of scope for anything in the github source, and instead depends on the server hosting the page. I know this isn't meant to be super secure, but it's still worth a mention.

Typos aren't making the hash part turn into something else. Like your parent comment explained to you, the hash part is not sent to the server. If you go out of your way to mangle the URL then of course a mangled URL without hash will likely get logged to the server. But I'm not sure how one would manage to go so much out of the way that they mangle the URL in a way that removes the hash.

You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc.

Percent encoding is particularly bad since it may also bloat the length causing truncation and the decompress to fail. There's endless footguns with URLs.

> You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc.

If an app is mangling the URL by stripping the query and hash components, then it is breaking URLs and you have a bigger problem than worrying about URLs being logged. Stop using such apps immediately and report the bugs to the app developers.

To my original point, if those changes to the URL cause the browser to not parse the hash component then it will be sent to the server and get logged.

The idea is nice, but unreliable. The original intent was simply to link a section of a page and it should fail gracefully (and it does when used as intended).

very easy for the server to intentionally (or by compromise) add a one liner to send the hash text up.

Reply on news.ycombinator.com