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

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