Dave Watts wrote:
>
> When you use the CFLOCATION tag, the server sends back a Location header.
> The browser doesn't display the page which contains the Location header, but
> it does receive it. It then requests the URL specified in the Location
> header. So, using your step-by-step approach, here's what happens:
>
> - user submits page 1 thereby requesting page 2
> - server processes page 2
> - server returns page 2
> - browser reads Location header, which says "get page 3"
> - browser requests page 3
> - server processes page 3
> - server returns page 3 and browser displays it
>
> This is very easy to see, if you use a recording proxy.
Indeed easy. But wrong :)
Although your description of what happens is quite accurate for the
current browsers, you are depending on features that are not compliant
with the HTTP/1.1 specification.
<quote>
10.3.3 302 Found
[..]
If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
10.3.4 303 See Other
The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a
substitute reference for the originally requested resource. The 303
response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable.
The different URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.
</quote> RFC 2616 HTTP/1.1
A redirected POST should result in a POST for the next page, not a GET,
and a POST is never allowed to be without user intervention. If you use
cflocation in response to a POST from a HTTP/1.1 compliant browser the
user will get a popup asking him if he wants to be redirected, which is
usually not desired behaviour.
Jochem
______________________________________________________________________
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists