I wouldn’t get too hung up on the names, because this is a case where the spec and the implementations don’t quite match up.
Here’s an example that’s common practice. Let’s say we submit a form via POST to a URL /submit. That URL does some processing then returns a 302 response, redirecting to a URL /view. Yet this behavior doesn’t quite match the spec:
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
But browsers certainly don’t ask for permission every time a site 302 redirects after a POST request. The behavior we observe for a 302 actually matches the spec’s description of a 303:
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.
So, in theory, a 302 and a 303 should behave differently, but in practice, they behave identically.
In light of this, I suggest we don’t get too hung up on the names and instead think about the desired behavior. Such as:
- Do you want the redirect response to be cacheable? Meaning, if a user visits the misspelled URL a second time, should the browser double check that the redirect is still in place? Or should it use its cache to know about the redirect and just request the corrected URL? If you want the redirect response to be cacheable, then a 301 is your simplest option.
Or 2) if someone submits a POST request to a misspelled URL, do you want to ignore the POST data and just have the user GET request the corrected URL? (If so, then 302 or 303.) Or do you want to keep the POST data intact and have the user POST request the corrected URL? The browser will ask the user to confirm re-submitting the POST data. (If so, then 301 or 307.)
All things considered, I think 301 is your best bet. For a misspelled URL, I think cacheable is desirable. And for POST requests… well, in this scenario, we probably don’t care too much one way or the other… but the safest option is to not throw away the POST data and instead ask the user what they want to do.