- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 21 Jun 1995 01:08:30 +0200 (MET DST)
- To: koen@win.tue.nl (Koen Holtman)
- Cc: S.N.Brodie@ecs.soton.ac.uk, www-talk@www10.w3.org
[I'm following up on my own reply. Sorry about that.] Koen Holtman: >S.N.Brodie@ecs.soton.ac.uk: >>I am POSTing form contents (at a CERN 3.0 server) and receiving a >>redirect. Once the user has confirmed that it is OK to redirect, >>should I send the POST command and the form data to the new URL, >>or issue a GET? I had presumed that I send the POST. > >Sending a POST is the correct thing to do. The (March 8 1995) draft >is not completely clear about this, but this seems to be the current >consensus. By `current consensus' above, I meant the consensus on how the (March 8 1995) draft should be interpreted. I have just done some tests on a few browsers, and it seems that the convention among browsers is to change the POST to a GET on redirect. It could be argued that this behavior conforms to older internet drafts of the http protocol (e.g. the one dated 5 Nov 1993). So if you are a browser writer, my advice would be do to first try a POST for the redirect, and if the POST fails, then try a GET because of downward compatibility reasons. If you are a CGI script writer, my advice would be to redirect a POST request only to a script that can process both GET and POST requests. Note that most people would agree that a mechanism to redirect a POST on URI A to a GET on URI B would be much more useful than a mechanism to redirect a POST on URI A to a POST on URI B. Only the second, less useful, mechanism is offered by the March 8 1995 draft. Koen.
Received on Tuesday, 20 June 1995 19:08:50 UTC