WordPress.org

Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 9 years ago

#4183 closed defect (bug) (fixed)

HTTP Status 302 has wrong text defined for HTTP 1.1

Reported by: nberardi Owned by: rob1n
Milestone: 2.3 Priority: normal
Severity: minor Version: 2.2
Component: Administration Keywords: http, status, code, 302, 303, 307
Focuses: Cc:
PR Number:

Description

For the method status_header() in http://trac.wordpress.org/browser/trunk/wp-includes/functions.php?rev=2623#L1852, it defines HTTP Status code of 302 for the text "Moved Temporarily".

This is the correct behavior for HTTP 1.0 however in HTTP 1.1 the Status Code 302 is defined as "Found" and Status Code 307 is defined as "Moved Temporarily".

302 Found
http://tools.ietf.org/html/rfc2616#section-10.3.3

303 See Other
http://tools.ietf.org/html/rfc2616#section-10.3.4

307 Temporary Redirect
http://tools.ietf.org/html/rfc2616#section-10.3.8

The history of why this change was made, was because of the abuse of the 302 Status Code for as application level redirects. So the governing body decided to split 302 out in to 3 different codes. "302 Found" was suppose to be the anti-"404 Not Found". "303 See Other" is what most developers use Status Code 302 for, meaning that you should see this other site after a certain process as occurred such as a POST. And then you have "307 Temporary Redirect" as in we are temporarily redirecting traffic because the page you requested is being worked on.

The change that I request is that "303 See Other" be used instead of the current "302 Moved Temporarily", or in the very least you update the text to reflect the "302 Found". I hope you take this in to consideration when releasing you next major release.

Change History (14)

#1 @nberardi
13 years ago

  • Type changed from defect to enhancement

#2 @rob1n
13 years ago

  • Owner changed from anonymous to rob1n
  • Type changed from enhancement to defect

Nah, it's a defect :).

#3 follow-up: @rob1n
13 years ago

Should we detect whether the headers received are HTTP 1.1 or 1.0?

#4 @nberardi
13 years ago

  • Cc nberardi added

#5 in reply to: ↑ 3 @nberardi
13 years ago

Replying to rob1n:

Should we detect whether the headers received are HTTP 1.1 or 1.0?

Yes I think it would be necessary since the text changed. Are there any statistics on how much traffic is HTTP 1.0?

#6 follow-up: @Otto42
13 years ago

302 and 307 under HTTP 1.1 have the same basic effect, except that HTTP 1.0 agents don't understand 307.

I vote for just changing the text to "Found" and leaving it a 302 for now. In the future, when 1.0 agents go away, moving to a 307 would make sense. Trying to detect the version and sending a 302/307 could be done, but would make more sense if we abstracted out the HTTP version to some other functions or some such thing, since there are proxy issues that are also associated with sending 1.1 headers to 1.0 proxies.

#7 in reply to: ↑ 6 @nberardi
13 years ago

Replying to Otto42:

In the future, when 1.0 agents go away, moving to a 307 would make sense.

Actually you probably want to do a "303 See Other" in the future instead of a "307 Temporary Redirect".

Temporary Redirect is only suppose to be used for instances where you need to redirect traffic temporarily, say in the case where you are updating your website and need to move all the traffic to another page.

See Other is more used for redirecting to another URL after a post is done. For instance I filled out a user registration form and POSTed the values to the server and the server wants to send me back to the home page. That is when you would use the "303 See Other". This is all according to the RFC specification.

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.

But I do agree with keeping the 302 the same but changing the text until HTTP 1.0 clients disappear.

#8 @JeremyVisser
13 years ago

I just telnet'ed into my Apache server, and typed this:

GET / HTTP/1.0

However, the server responded in HTTP 1.1:

HTTP/1.1 200 OK
Date: Wed, 25 Apr 2007 01:55:04 GMT
Server: Apache/2.2.3 (Ubuntu) mod_python/3.2.10 Python/2.5.1c1 PHP/5.2.1
Content-Length: 5544
Connection: close
Content-Type: text/html; charset=UTF-8

So, if Apache doesn't bother, we may as well always respond in HTTP 1.1 as well.

#9 @rob1n
13 years ago

But why fix it, if HTTP/1.1 browsers understand HTTP/1.0's 302? It seems pointless to me... in the future, if HTTP/1.0 disappears, then we can just switch it all over.

#10 @andy
13 years ago

Has anyone ever seen a user agent that acted on the text rather than the number?

#11 @rob1n
13 years ago

I say we just change the text to 302 Found, then leave it at that.

#12 @rob1n
13 years ago

  • Status changed from new to assigned

#13 @rob1n
13 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [5446]) New status_header code, and WP-DB bail() errors send a 503 Service Unavailable. see #2409

Also, the new header code to text array has 302 as Found. fixes #4183

#14 @hakre
9 years ago

Related: #13909

Note: See TracTickets for help on using tickets.