[whatwg] page refresh and resubmitting POST state

On Sun, 24 May 2009 15:41:12 +0100, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

>> This problem can be elegantly solved within existing standards: Opera  
>> simply goes back in history without resubmitting forms, and resubmits  
>> only when user clicks standard Reload button (or F5, etc.)
>
> Firefox does that too, at least in 3.5b4pre.  But this solution only
> works if the page is still in the browser's history cache.  Browsers
> can't keep pages in their cache forever -- it fills up and needs to be
> emptied.

It only needs to keep it as long as Back history is kept, and could get  
rid of it as soon as this entry is removed from Back/Forward history.

>> * If it's not safe to resubmit, use status 303. I know it's not very  
>> convenient, but can be implemented reasonably well and works with  
>> existing browsers.
>
> The problem is that since HTTP is stateless, you don't have the data
> available to show a confirmation page.

You store the data on server side, and redirect to URL that contains  
unique ID for this data.

It's just a few lines in PHP (and similar solutions shuold be possible in all web frameworks):

$id = uniqid();
$_SESSION[$id] = $_POST;
header("Location: [?]/result.php?id=$id",false,303);

and later:

$_POST = $_SESSION[$_GET['id']];

This works even for multiple submissions done in parallel and it's pretty  
secure and tamper-proof.

>> * If it's safe to resubmit, use PUT method (allowed in HTML 5), which  
>> is idempotent by definition.
>
> Theoretically, but not really in practice.  Someone else might have
> PUT something new at the URL since your last PUT, or DELETEd it, or
> otherwise done something to it.  In that case, you'd overwrite their
> modifications.  PUT is only practically idempotent if only one user is
> modifying the resource, as far as I can tell.

That's a good point.

Is it possible for HTML 5 spec to say that browsers may re-send PUT without asking? (and that authors should use PUT only when resending is not going to cause this problems).

-- 
regards, Kornel Lesinski

Received on Sunday, 24 May 2009 08:41:47 UTC