Home / Browse / Webware for Python / Mail / Archive

Webware for Python

Email Archive: webware-discuss (read-only)

[Webware-discuss] POST Idiom Advice.

From: Ian Sparks <ians@et...> - 2002-11-27 15:01

This isn't a webware question per-se but I'd like to ask how people =
handle POST's.

For instance, I have a page which provides a list of items for deletion. =
Check a checkbox on the rows you want to delete and hit the "Delete" =
button.

def delete(self):
    self.killSelectedRecords()
    self.writeHTML()

i.e. the user gets a page back with the regenerated list (less those =
deleted).

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).

My temptation is to do :

def delete(self):
    self.killSelectedRecords()
    self.response().redirect(self.response.url()) #pseudocode!

i.e. redirect the browser to do a GET on the page they just POSTed to.

Is this what other folks do? What is the approved idiom? What are the =
trade-offs and hidden dangers?

- Ian Sparks.
   =20

Thread View

Thread	Author	Date
[Webware-discuss] POST Idiom Advice.	Ian Sparks <ians@et...>

Re: [Webware-discuss] POST Idiom Advice.

From: Nick Murtagh <nickm@go...> - 2002-11-27 15:29

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

Re: [Webware-discuss] POST Idiom Advice.

From: david e <bbs@fa...> - 2002-11-27 16:13

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).

Re: [Webware-discuss] POST Idiom Advice.

From: Ian Bicking <ianb@co...> - 2002-11-27 18:21

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

Re: [Webware-discuss] POST Idiom Advice.

From: Nick Murtagh <nickm@go...> - 2002-11-28 10:05

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.