php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32263 Location sets 302 on HTTP/1.1+POST, should be 303
Submitted: 2005-03-10 14:21 UTC Modified: 2005-03-14 20:28 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: pornel at despammed dot com Assigned: rasmus (profile)
Status: Closed Package: HTTP related
PHP Version: 5.0.2/cgi, 4.3.3/mod tested OS: win
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: pornel at despammed dot com
New email:
PHP Version: OS:

 

 [2005-03-10 14:21 UTC] pornel at despammed dot com
Description:
------------
HTTP/1.1 user-agents should be redirected after POST request using 303 status.

According to RFC2616 user-agents MUST NOT redirect POST on 302 status (unless confirmed by the user, AFAIK only Lynx does that), so 302 is not the best choice in this situation.

In short: if (HTTP/1.1 && POST) default_redirect_status=303.




Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-12 16:28 UTC] pornel at despammed dot com
<?php
header("Location: http://example.com");
?>

HTTP dialog:

POST /test.php5 HTTP/1.1
Host: localhost
Content-Length: 0

HTTP/1.1 302
Date: Sat, 12 Mar 2005 15:28:40 GMT
Server: Apache/1.3.27 (Win32) PHP/4.3.3
X-Powered-By: PHP/5.0.2
Location: http://example.com
Transfer-Encoding: chunked
Content-Type: text/html

0



POST /test.php HTTP/1.1
Host: localhost
Content-Length: 0

HTTP/1.1 302 Found
Date: Sat, 12 Mar 2005 15:26:03 GMT
Server: Apache/1.3.27 (Win32) PHP/4.3.3
X-Powered-By: PHP/4.3.3
Cache-Control: no-cache
Location: http://example.com
Transfer-Encoding: chunked
Content-Type: text/html

0
 [2005-03-12 19:02 UTC] rasmus@php.net
I think most clients actually treat a 302 like a 303 in that case.  But yes, this should be fixed.  Unfortunately we don't have a clean way of doing this without adding the proto_num to the request_info struct.  Changing that struct would be a bad idea for PHP4 at this point.  I'll look into doing it for PHP 5.1.
As a workaround, just do:
header("Location: /foo",true,303);

 [2005-03-14 20:28 UTC] rasmus@php.net
This is fixed correctly CVS HEAD now.  We still may hack something based on SERVER_PROTOCOL into 4.3/5.0.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 15:01:30 2024 UTC