Is there still a use case for HTTP 301 rather than HTTP 308 to indicate that a resource has moved (particularly in a ReST server)?

3
votes

I am specifying a ReST service. I recently stumbled on this IETF draft document which could be interpreted as suggesting that ReST services should always return 308. Note that the document seems to have expired without being superseded (I'm not very clear on the IETF process).

I had it in my mind earlier that a service should return "301 Moved Permanently" for a GET and a "308 Permanent Redirect" for a POST to ensure it is not inappropriately converted to a GET (by something trying to be clever).

Uses of both 301 and 308 seem to be expressed in terms of SHOULDs and SHOULD NOTs rather than MUSTs and MUST NOTs, so it is unclear what "the right thing" is philosphically.

Pragmatically 301 for GET and 308 for POST should work. 308 for GET is not wrong as the current revision at the time of writing includes an example of 308 being produced in response to a GET. Now there is a deployment concern that if a client doesn't understand 308 it should treat it like a 300 (rather than a 301 which makes more sense to me) but 308 is now widely understood so the question becomes if or why should you ever use HTTP 301?

If 308 is essentially a bug fix for 301, why isn't 301 officially deprecated in HTTP/1.1? Is there a legitimate use case for converting a POST into a GET for a redirect in ReST or in more generally in HTTP?

For 301 HTTP/1.1 says:

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

Why was that ever a good idea? Is it still valid anywhere?

See also:

1
resthttphttp-status-codes
tools.ietf.org/html/rfc7538 Generally it's your (design) decision. As in your example there would not be a huge difference. But if you standardize it, you would not need to worry about different cases. Just ask yourself is there a downside using the newer 308 over the old 301? If not use the newer one. – Tom-Oliver Heidel
My hope is that with a well defined protocol like HTTP we can move towards designs where there is one right way to do things. In this case I think its 308 (I'm asking 'the internet' why I'm wrong - or possibly right) but if 308 is a bugfix for 301 why didn't the IETF deprecate 301. Does 301 still have a sensible use case separate from 308? – Bruce Adams
308 is not a bug fix. It's rather an extension to secure that the same method will be used (e.g. POST -> POST). How a program or browser reacts to it depends on the implementation. 301 won't deprecate that fast. 308 is there to add another layer of protection/security into the protocol. – Tom-Oliver Heidel
How a client should interpret status codes is mostly covered in the standard so its not implementation dependent. If I returned a 400 for a resource that does not exist instead of 404 I would be wrong. There are systems, including "ReSTish" APIs that do not follow the standard properly. There are may be a few ambiguities (301/308 possibly being one). 301 won't disappear from implementations overnight. The question is does 308 make it redundant? (if so the right thing is to always use 308 and label 301 as deprecated). – Bruce Adams
Why was that ever a good idea? Is it still valid anywhere? If we are lucky enough, we may get some input from Julian Reschke who authored the RFC 7538 and co-authored the RFC 7231 with Fielding. – cassiomolin

1 Answers

0
votes

If 308 is essentially a bug fix for 301, why isn't 301 officially deprecated in HTTP/1.1?

No, it's not.

The RFC 7538, which defines the 308 status code, doesn't invalidate or make 301 obsolete. It just defines another status code to fill a gap on the RFC 7231, which does not define a permanent variant of status code 307:

+-------------------------------------------+-----------+-----------+
|                                           | Permanent | Temporary |
+-------------------------------------------+-----------+-----------+
| Allows changing the request method from   | 301       | 302       |
| POST to GET                               |           |           |
| Does not allow changing the request       | -         | 307       |
| method from POST to GET                   |           |           |
+-------------------------------------------+-----------+-----------+

In practical terms, I still see 301 being largely used in SEO. And I've seen some HTTP clients that don't recognize 308.

Apart from the RFCs, let's have a look what MDN Web Docs from Mozilla say about 301:

The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL).

Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents align with it - you can still find this type of bugged software out there. It is therefore recommended to use the 301 code only as a response for GET or HEAD methods and to use the 308 Permanent Redirect for POST methods instead, as the method change is explicitly prohibited with this status.

Now see what Mozilla says about 308:

The HyperText Transfer Protocol (HTTP) 308 Permanent Redirect redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL).

The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method.

Note: Some Web applications may use the 308 Permanent Redirect in a non-standard way and for other purposes. For example, Google Drive uses a 308 Resume Incomplete response to indicate to the client when an incomplete upload stalled. (reference)