W3C home > Mailing lists > Public > www-amaya@w3.org > April to June 2000

RE: HTTP Redirect bug - more info

From: Dave J Woolley <DJW@bts.co.uk>
Date: Thu, 20 Apr 2000 17:29:09 +0100
Message-ID: <81E4A2BC03CED111845100104B62AFB58245DC@stagecoach.bts.co.uk>
To: "'www-amaya@w3.org'" <www-amaya@w3.org>
> From:	Fox One [SMTP:rockman66_1999@yahoo.com]
> 
> When submitting a form using the POST method, 
> if Amaya receives a redirect HTTP header, it
> tries to POST to that URL also. In other words,
> Amaya does the following:
> 
> HTTP out: POST: <url to cgi script>
> HTTP  in: <redirect to new url - an HTML document>
> HTTP out: POST: <url of HTML document>
> 
> The last POST is incorrect. Amaya should try a 
> GET for that document:
> 
	[DJW:]  
	No it should not.  Status 301 and 302 redirects 
	are supposed to be issued with the same method as
	the original request.  Broken behaviour in some
	browsers resulted in a lot or content authors who
	didn't read the specs using 302 to redirect to 
	a confirmation page.  As such redirects to GET were
	clearly needed, status 303 was added to cover them,
	in an early draft of HTTP 1.1 (if you just return
	Location:, but no Status: in a CGI script, you get
	a 302 redirect, or an internal redirect).

	Because of the existence of broken browsers, status
	307 redirects were added in later drafts of HTTP 1.1.
	This means the same as 302, for conforming browsers, but
	makes it clear that you don't want the browser to 
	assume that you were expecting broken 302 behaviour.

	If your application requires reliable redirect from POST
	to GET, it must return a 303 status.  Because of
	the misimplementations, using 302 for a POST is unsafe,
	although you should use it for GET.
Received on Thursday, 20 April 2000 12:34:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 April 2014 11:01:34 UTC