The following reply was made to PR general/4203; it has been noted by GNATS.
From: Dirk-Willem van Gulik <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: general/4203: redirect based on 404 turns POST into GET
Date: Wed, 07 Apr 1999 09:26:50 +0200
>Number: 4203
>Category: general
>Synopsis: redirect based on 404 turns POST into GET
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apache
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Tue Apr 6 23:10:01 PDT 1999
>Last-Modified:
>Originator: [EMAIL PROTECTED]
>Organization:
apache
>Release: 1.3.4
>Environment:
Linux 2.0.36
>Description:
I'm using ErrorDocument 404 directive to redirect to index.php3 so that I can
lookup the URL in a database and display
the corresponding page. This works OK, but when a POST form is used,
REQUEST_METHOD is GET, not POST, so PHP does not
use the content (even though it has a length, etc.) to create HTTP_POST_VARS.
>How-To-Repeat:
see above
>Fix:
If there is a redirect, the post needs to be redirected (at least for 404
redirects), which means REQUEST_METHOD should
be the same as REDIRECT_REQUEST_METHOD.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig- ]
[nored unless you are responding to an explicit request ]
[from a developer. ]
[Reply only with text; DO NOT SEND ATTACHMENTS! ]
Firstly; this seems a a _browser_ issue to me; i.e. it
is the browser who deceides to re-try with a GET instead
of a POST.
Secondly From RFC1945:
9.3 Redirection 3xx
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
required may be carried out by the user agent without interaction
with the user if and only if the method used in the subsequent
request is GET or HEAD. A user agent should never automatically
redirect a request more than 5 times, since such redirections usually
indicate an infinite loop.
Now I agree that there is some confusion (see for example how lynx does this
(http://www.ocf.berkeley.edu/~jeffwong/lynxstuff/webdesign/cgiforms.html)
as to whether this is right.
Now in the draft for HTTP/1.1 you see much the same story:
10.3 Redirection 3xx
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
required MAY be carried out by the user agent without interaction
with the user if and only if the method used in the second request is
GET or HEAD. A client SHOULD detect infinite redirection loops, since
such loops generate network traffic for each redirection.
Note: previous versions of this specification recommended a
maximum of five redirections. Content developers should be
aware that there might be clients that implement such a fixed
limitation.
So, can I close this PR ?
Dw.
