W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] page refresh and resubmitting POST state

From: Mike Wilson <mikewse@hotmail.com>
Date: Mon, 25 May 2009 12:14:48 +0200
Message-ID: <BAY116-DAV1112E6FF86933C5EB6D00CA4550@phx.gbl>
Kristof Zelechovski wrote:
> If the local document is being edited in Notepad and bound to 
> the validator via a file input control, refreshing the page 
> should resubmit the file.
> Chris

Ah, ok. I see no problem with the page author coupling the file
input control to the redisplay state, or whatever construct 
could be used to hint to the browser that this data can be
resubmitted without "harm". You would then avoid getting the 
resubmission question on refresh.

The hinting system could be useful whether we say that the
Refresh button's semantics is Redisplay or Redo. Both would 
avoid popping the resubmission question when all fields are 
hinted harmless, but they would have different behaviour for 
when there is a mix of "harmless" and "harmful" fields.

Of course, the same goal could be achieved with a completely 
different solution. This was just an example to get going.

On a side note, your example makes me think of whether what to 
post at a page refresh is covered by any spec. The normal 
behaviour is that the browser posts the same data as sent in
the original POST request, so if you have done any edits in the
form between original POST and Refresh, they will be lost (this
could even be subject for a "discard edits?" question ;-).
Though as you mention, and I guess for practical reasons, the
file contents of an uploaded file doesn't reflect the original
request but instead the current file contents. Nothing wrong
with that, but maybe this also deserves spec space.

So, going back to my main point. All this is about de-facto, or
potential future, browser behaviour and thus would be 
interesting in a spec about just that. The HTML5 effort is the 
closest match I've found for this subject.

Best regards
Mike Wilson
Received on Monday, 25 May 2009 03:14:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:12 UTC