Not a bug Route Filter doesn't 301 to new URI

Some of it is down to whether or not we canonicalize on the particular page, which we don't necessarily do on every page so in that regard it may be expected. However, those pages aren't really the primary ones.

In your particular example, I get a 301. The fact that you're seeing the URL change means that there is a redirect happening, so what redirect code are you seeing?
 
To not screw up my pages in Google index, I made another filter. There's a static page called "privacy". I set the route filter to

search:
/pages/privacy/

replace:
/stuff/privacy/

So if you request
http://www.wewota.de/pages/privacy/

you will be redirected to
http://www.wewota.de/stuff/privacy/

However, I don't actually know how. :D
Because if you check the header from the old URI, you'll get a 200 OK:
http://www.internalscripts.de/werkzeuge/http-header-abfrage.php?url=http://www.wewota.de/pages/privacy/

If you try to call an old vBulletin link, there is a 301. Like here:
http://www.wewota.de/showthread.php?t=312

Headers:
http://www.internalscripts.de/werkzeuge/http-header-abfrage.php?url=http://www.wewota.de/showthread.php?t=312

Those are the official redirection scripts from back then (March 2011, I believe).

Btw, from here:
http://www.wewota.de/threads/310/

to there:
http://www.wewota.de/threads/xenforo-1-0-aktuelle-version-1-0-4.310/

There's no visible 301 either.
Look:
http://www.internalscripts.de/werkz...age.php?url=http://www.wewota.de/threads/310/
 
Either the results of that script are cached or its just plain wrong. You can see the 301 in Chrome:

upload_2013-8-13_11-20-35.webp
 
Okay, I contacted the guy who hosts that script. He told me that both wget and Chrome are going for the GET request where his tool goes for the HEAD request. Asking curl for the headers of /threads/310/ results in the same as the tool shows. I.e. no 301 but 200.

Code:
murathd:~ rellek$ curl -I http://www.wewota.de/threads/310/
HTTP/1.1 200 OK
Date: Tue, 13 Aug 2013 15:52:12 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.4.17-1~dotdeb.0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-control: private, max-age=0
Set-Cookie: xf_session=29484b2c56de8693d5a44c47f5728489; path=/; httponly
X-Frame-Options: SAMEORIGIN
Last-Modified: Tue, 13 Aug 2013 15:52:12 GMT
Content-Length: 67578
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8

murathd:~ rellek$

So this is just for me to understand; how does this work in XenForo? Are there differences between a usual GET/POST request and a HEADER request or is there maybe something that could cause trouble?

That asked, I don't actually consider this a bug any more, I'd just like to understand :)
 
I believe we only do the canonicalization on GET requests. I suppose we could do it on HEADs as well but it's the sort of thing that isn't how a browser (or search engine) requests it.
 
Top Bottom