Tracback should 301 redirect instead of 302

[joostdevalk]

If someone opens a trackback url without actually sending a trackback, he is redirected to the original post. That redirect is a 302 redirect. This causes all kinds of issues as links to the trackback URL are included in many themes by default, search engines follow these links and search engines can't really handle the 302 redirect well.

Since opening a trackback URL with a normal browser is never meant to give you anything, it's quite safe to make the 302 into a 301 redirect.

I have tested this fix and have found it to work perfectly.

[joostdevalk]

Patch

[joostdevalk]

The commit bit was a bit too early perhaps :P

[JeremyVisser]

Nope, looks good.

[matt]

The redirect is basically an error condition, not browser detection. I don't think sending a permanent redirect is the right thing to do, because it's not a permanent condition and shouldn't be cached by, for example, proxies.

[joostdevalk]

Then you shoudl send a 404, and not a 302. A 302 says the content is to be found elsewhere, which is not true.

[markjaquith]

301 is not correct. 404 is not correct either.

303 is a possibility.

---

303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response.

---

No proxy issues here, as 303s shouldn't be cached. And it doesn't imply that the redirected URL is a substitute for the original URL.

[JoostdeValk]

Sounds good to me! Adding a new patch.

[JoostdeValk]

Patch 2

[Otto42]

303 is the correct way to do this, I say commit it.

For reference, the 300 codes work like this (under HTTP 1.1) :

• 300 Multiple Choices (like if you offer different languages.. not used much)
• 301 Moved Permanently (obvious)
• 302 Found (temporary redirect - deprecated in favor of 303 and 307)
• 303 See Other (redirection to be used after a successful POST, user agent should do a GET on the redirected URL)
• 304 Not Modified (user agent did a conditional GET but the document was not changed since the time given)
• 305 Use Proxy (the URL must be accessed through a proxy, the Location: gives the proxy that must be used)
• 306 Unused
• 307 Temporary Redirect (a real temporary redirection, a user agent doing a POST should do a repost to the new URL.. often causes the browser to ask the user for confirmation to do that)

[Otto42]

Actually, on thinking about it, the correct way is not so obvious. A 301 is correct for a browser, who didn't actually send any sort of trackback, but a 303 is correct for a system actually sending a trackback. Perhaps there needs to be some more robust handling here.

[joostdevalk]

how do you mean "robust"?

[Otto42]

After looking at it closer, I see that a successful trackback already sends back a 200 response (with some XML stuffs). The redirect response only occurs when you use a browser (or other user agent that is not actually doing a trackback).

Given this, and the fact that the trackback specification makes no mention of what to do when trackbacks URIs are called without the corresponding trackback POST data, I would have to say that 301 is the correct response. Redirect the agent to the original post, and 301 will make search engines ignore those URLs in favor of the post URLs.

A 303 will not solve the search engine problem, and is arguably the wrong thing to do when you're not redirecting from a script that accepted valid input. A 302/307 doesn't solve the search engine problem either. The 301 solves the search engine problem, even if it does imply that the trackback URL is no longer valid. It won't affect actual trackback agents, since you're not sending them the 301 at all.

+1 for 301.

[markjaquith]

301 is cacheable (for instance, by proxies). If someone clicks a trackback URL link through a proxy and then someone through that same proxy tries to send a trackback, the 301 from before might be cached, and the Trackback might fail. It also suggests that the new URL is a substitute reference for the requested URL. It is not.

307 is also incorrect because it suggests that the new URL is a substitute reference for the requested URL.

302 has the same problem.

405 is a really specific match, but doesn't allow us to do a redirect (PHP sends a 302 if you try), so that loses because of user-unfriendliness

303 is the only one that allows the redirect but does not suggest that the redirected URL is a substitute for the original URL.

But in any case, this is going to have to miss the 2.3 boat. We can resume discussion once 2.3 is branched off next month.

[westi]

(In [7319]) Allow plugins to filter the redirect status as well as the location. See #4790.

[westi]

Closing as WONTFIX.

• Changing to 301 is not possible due to the caching issues.
• Changing to 307 is incorrect as mark has already said.
• Changing to 303 doesn't help a search engine so doesn't improve the issue raised.

I have added a filter to the status which will allow a plugin to override it for those people who want a different HTTP status in this or another redirect case.