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

Reply via email to