Webware for Python

Ian Sparks wrote:
> This isn't a webware question per-se but I'd like to ask how people handle POST's.

I think the best thing to do is split it between

(a) a page that does presentation logic (ie displays list of items)

(b) a separate page that takes querystring or form parameters, and 
performs some action (ie delete an item from the list), then redirects 
to (a) or some appropriate destination.

Refreshing (a) never performs an action. The user never notices the
existence of (b).

Nick

Always have a hidden field with your forms that has got a random 
value for "one time" only actions. Generate a suitable number/string 
and save this to the user session. Then before you perform any 
actions make sure this value 1) exists, 2) isn't "used", 3) then mark 
it as used.. Now you should be safe for all kinds of Reloads, Back 
buttons etc.. Good luck.


>This isn't a webware question per-se but I'd like to ask how people 
>handle POST's.
>
>
>The problem for me is the Browser Refresh button. If you click it 
>now its not going to do what it says ("Refresh"), its going to 
>re-post the delete action (which could be bad).

On Wed, 2002-11-27 at 09:01, Ian Sparks wrote:
> def delete(self):
>     self.killSelectedRecords()
>     self.response().redirect(self.response.url()) #pseudocode!

This is what I do.  It works well.  I keep a list of messages to display
to the user in the session, so I add a message, redirect, and then the
message is displayed when they get to the next page (and removed from
the session).

If you read the HTTP spec, there's a particular response code that is
best to use in this situation, but I can't remember which it is (it's in
the 300's).

  Ian

Ian Bicking wrote:
> If you read the HTTP spec, there's a particular response code that is
> best to use in this situation, but I can't remember which it is (it's in
> the 300's).

Interesting...

(from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3)

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.