XF 1.5 Suggestions on redirecting posts with # character

[mono]

I had an issue few months ago that moderators merged three old large threads which I hadn't noticed. The result is a one big thread with broken links and totally mixed up posts. Now i'm trying to write redirects from existing links to new ones, but the main issue is that nginx rewrite rules don't understand the "#"character inside these links. Most of them look like this: threads/thread-title.1234/page-115#post-310043
Any suggestions on this?

 

[Kirby]

It is impossible perform redirects on the webserver based on anchors; browsers do not submit this information in the HTTP request.

If you need smth. like this, it has to be done with client side support code.

 

[Mr Lucky]

I had an issue few months ago that moderators merged three old large threads which I hadn't noticed. The result is a one big thread with broken links and totally mixed up posts.

I'm not aware that links get broken by merging threads, either something went wrong or that is a serious bug.

 

[mono]

It is impossible perform redirects on the webserver based on ahcors

It is not anchors, but links generated by the engine

it has to be done with client side support code

Yes, looks like this. Do you know any ready-to-go solutions?

I'm not aware that links get broken by merging threads, either something went wrong or that is a serious bug.

I'm not sure if this is a bug or not, but if you merging threads they'll change their address to another one, so every link to an old address will be broken after that.

 

[Mr Lucky]

I'm not sure if this is a bug or not, but if you merging threads they'll change their address to another one, so every link to an old address will be broken after that.

I think that must be a bug, I thought that the xenforo linking system uses the thread/post id number just for that very reason. I know if you change a thread title, the link still works so I can't think why it shouldn't work when merging.

I would report that as a bug

 

[Kirby]

I don't think there is a bug.

This is a permalink and will stay valid/get redirected if the post is moved to another thread, for example by merging this thread into another one:
https://xenforo.com/community/threa...th-character.148227/post-1257215#post-1257215
eg.
https://xenforo.com/community/threads/this-thread-does-not-exist.0/post-1257215#post-1257215

This is not a permalink and will get broken if the thread does get merged into another thread:
https://xenforo.com/community/threa...ing-posts-with-character.148227/#post-1257215

 

[MySiteGuy]

It is impossible perform redirects on the webserver based on anchors; browsers do not submit this information in the HTTP request.

The only time browsers do not submit with the anchor is when they are already on that page, and the user clicks an anchor tag to a target within the same page... the browser knows it doesn't have to fetch the page again. When the user clicks a link on a page to another page and the link contains an anchor tag, the browser sends it as part of the request URL.

 

[Kirby]

When the user clicks a link on a page to another page and the link contains an anchor tag, the browser sends it as part of the request URL.

It does not (well ... at least it should not, and as far as I can remember no mainstream browser does), please read RFC 3986

As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. Although this separate handling is often perceived to be a loss of information, particularly for accurate redirection of references as resources move over time, it also serves to prevent information providers from denying reference authors the right to refer to information within a resource selectively.

 

[MySiteGuy]

Interesting, I had seen them before in my server logs and went by that. I've gone back and double checked and found entries such as
GET /threads/68rfe-how-long-will-it-last.250859/#post-2424771

But you're right.... the other fields in the logs for these entries do not contain a user agent or referrer field, so it's a web crawler of some sort sending them (and one more blocking rule to add!).