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 <div>On 8/9/07, Jens Axel Søgaard <<a href="mailto:jensaxel@soegaard.net">jensaxel@soegaard.net</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 </blockquote></div>