[plt-scheme] Problem with Post-Redirect-Get in FireFox

From: Vladimir Zlatanov (vlado at dikini.net)
Date: Thu Aug 9 05:36:37 EDT 2007

Sorry for the dupe Jens, I forgot to send to list

I don't know about the plt-webserver. I had a lot of trouble in the past
with browsers, using other implementations.

It generally pays off for GET->POST->REDIRECT->(GET|HEAD) to force the
no-cache behaviour. As far as I remember even then you might hit problems,
but I can't recollect the exact cases, they are a
voodoo science.

The browser can choose to issue HEAD to check for status, although you
expect a GET instead. The decision GET|HEAD is due to the browsers' page
handling and caching logic, which isn't and can't be specified in the http
protocol specs, that's why the language in the RFC.


On 8/9/07, Jens Axel Søgaard <jensaxel at soegaard.net> wrote:
> Vladimir Zlatanov wrote:
> >     After adding the following headers, FireFox behaves normal again.
> >
> >        (make-header #"Pragma" #"No-cache")
> >        (make-header #"Cache-Control" #"no-cache")
> >        (make-header #"Expires" #"1")
> >
> >     But I still don't understand why these are necessary.
> >
> > Well, it is from the under-specified set of behaviour is http. They can
> > be and are interpreted differently
> > by different browsers.
> The text for 303 is as follows:
>    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.
> Ahh! The word "SHOULD" means:
>    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>       may exist valid reasons in particular circumstances to ignore a
>       particular item, but the full implications must be understood and
>       carefully weighed before choosing a different course.
> So one can't be sure that the page redirected to is fetched by GET.
> I am still a little puzzled by the fact that browsers behave differently
> with the rather standard POST-REDIRECT-GET pattern. Maybe my problem
> is due to the fact that I am redirecting to the same page that the
> POST stemmed from? Also, I couldn't see any cache headers in the
> web-server source where redirect-to is implemented, but perhaps
> those headers are present somewhere else?
> --
> Jens Axel Søgaard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070809/816eb217/attachment.html>

Posted on the users mailing list.