[varelaz]

How is this different from GET arguments in the URL? I mean is this relates only to URL fragment, because javascript can parse URL parameters as well and any spam site can abuse it even with rewrite in the path part in the URL.

[jan_Sate]

GET arguments are not redirected to the spam site because when the url redirection site has received the GET argument, the GET argument would generally be discarded/disregarded before redirecting the user to the spam site.

[varelaz]

But you're not in control of fragment part. Server doesn't receive fragment for request, it's all managed completely by the browser. To handle this you need to do client side redirect with javascript.

[jan_Sate]

Good question.

I haven't tested that but I think it's possible to modify the fragment with Javascript: https://stackoverflow.com/a/4282075

So my idea would be getting looo.ong to create a special client-side redirection webpage that would remove the fragment part using Javascript before performing the redirection with Javascript. And no. Using HTTP redirection response on server side won't work.

EDIT: I've actually seen URL redirection websites that removes the fragment part so it should be doable. Perhaps the purpose of that is to avoid spam abuse.

[Izkata]

> I haven't tested that but I think it's possible to modify the fragment with Javascript

Yes, this is how single-page apps allowed linking to subpages before history.pushState existed.

[factormeta]

thanks to the need for ES to accommodate SPA (one of the worse thing that has ever happens to the web), that allows ES/JS to change the URL of the page as long as it is within the same domain. What could go wrong. Don't try to make web a QT replacement. Crete your own freaking interface. Stop hijacking web as document based platform to squeeze everything in there.