NYCPHP Meetup

[Adam Maccabee Trachtenberg]

On Fri, 30 Jan 2004, Ophir Prusak wrote:

> I was recently tasked to fix this exact issue.
> In a nutshell, our solution was simply to change "post" to "get" in most
> of our forms.
>
> First of all, you need to check where this makes sense.
>
> For all the forms where submitting the form would not make any changes
> to the data (only use db selects) this was fine. For example, in all of
> our search and report pages.
>
> For all the forms where submitting the form could possibly change data,
> we chose not to change it to get, and leave the "this page has expired"
> error message. For example, if the user is inserting a new record into
> the database.

Roy Fielding would be so proud. If you read the HTTP RFC, you see
that you're not supposed to alter any content as a result of a GET
request. See section 9.1.1 of RFC 2616:

> In particular, the convention has been established that the GET and
> HEAD methods SHOULD NOT have the significance of taking an action
> other than retrieval. These methods ought to be considered
> "safe". This allows user agents to represent other methods, such as
> POST, PUT and DELETE, in a special way, so that the user is made
> aware of the fact that a possibly unsafe action is being requested.

Of course, nobody actually pays attention to that portion of the
spec. I would guess, however, that's why many browsers throw up a
"contents may have changed" page when you try to go back to a POSTed
page, since the assumption is that you've altered something as to make
the original form potentially incorrect.

-adam

-- 
adam at trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!