www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <dirk.vangu...@jrc.it>
Subject Re: general/4203: redirect based on 404 turns POST into GET
Date Wed, 07 Apr 1999 07:30:01 GMT
The following reply was made to PR general/4203; it has been noted by GNATS.

From: Dirk-Willem van Gulik <dirk.vangulik@jrc.it>
To: sroussey@network54.com
Cc: apbugs@hyperreal.org
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:     sroussey@network54.com
 >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 <apbugs@Apache.Org> 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.

Mime
View raw message