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

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.

Cheers,
Vlado

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>