Re: [whatwg] page refresh and resubmitting POST state
On Thu, 11 Jun 2009, Jeremy Orlow wrote: On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. This would cause additional network round-trips which is suboptimal. One alternative is to detect the case where JS is enable, and if it is, use pushState() and XHR to do the POST in the background and avoid the page load altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] page refresh and resubmitting POST state
On Mon, 15 Jun 2009, Mike Wilson wrote: On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. As I pointed out in a followup to Jonas's mail: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019937.html doing PRG with current technology has the drawback of losing the page state. This can be patched back again by adding query params to the URL but this isn't good for all scenarios (see below). I think generally speaking if the user experience is being tweaked to this level, then it's best to just do a JS-based Web app rather than relying on multiple page loads from the server. So instead of navigating the entire browsing context, just do an XHR POST, update the UI accordingly, and pushState() to get the new UI into the history. On Sun, 24 May 2009, Aryeh Gregor wrote: One workaround is to just stick the info in the query string of the GET. One problem with this is that it makes it easy to trick users into thinking they've just done something alarming: you can link to confirmmove.php?page1=Main_Pagepage2=Main_Page_ON_WHEELS, and the user will think they actually just moved the page (the software told them so!). Another problem is that sometimes there's way too much data to fit into a query string. For instance, in MediaWiki you can move a page with all its subpages. There might be hundreds or even thousands of these, and a success/failure message is printed for each, with the reason for failure if appropriate. This might be too long to fit in a GET. Just stick the data into the query parameters, including the user's ID, then sign the query parameters, and when serving the page, check the signature and check the user's ID matches the cookie. Adding data to the URL makes sense in some scenarios, but not in others. Often the application needs to hold on to state shared by a sequence of pages in the same browsing context, but at the same time not wanting this state to be shared with the same set of pages in another browsing context. This rules out cookie-based state as this is shared by all browsing contexts in the user agent. That's what the Web Storage sessionStorage API is for. A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the user takes several similar actions at once (e.g., moving a number of pages at once in multiple tabs). Using sessionStorage can be used to work around this somewhat, at least in AJAX apps. For server-oriented webapps a solution that doesn't rely on script is preferred. This means the server should be able to transmit browsing_context-scoped state to the client and have it automatically sent back on any following request. Something like browsing_context-oriented cookies. If we want to support this, then that would be a new feature for Cookies, I guess. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] page refresh and resubmitting POST state
Ian Hickson wrote: On Fri, 22 May 2009, Mike Wilson wrote: I can see some usefulness for adding a couple of subjects to the HTML5 spec: - how browsers should handle page refresh, in particular for pages received through POST (= do you want to resubmit?) Done. Nice, thanks. - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) On Fri, 22 May 2009, Jonas Sicking wrote: This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. snip On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. As I pointed out in a followup to Jonas's mail: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019937.html doing PRG with current technology has the drawback of losing the page state. This can be patched back again by adding query params to the URL but this isn't good for all scenarios (see below). [...] Defining some support in the browser could replace or simplify parts of these solutions. I'm sure people are open to suggestions. I wouldn't worry about whether they're in scope for HTML5 or not; if they're not, we can always redirect you to the right group. The information I've compiled goes outside the subject of this thread, so I'll explore further parts of the state handling problem in a separate mail thread titled html5 state handling: overview and extensions. On Sun, 24 May 2009, Aryeh Gregor wrote: One workaround is to just stick the info in the query string of the GET. One problem with this is that it makes it easy to trick users into thinking they've just done something alarming: you can link to confirmmove.php?page1=Main_Pagepage2=Main_Page_ON_WHEELS, and the user will think they actually just moved the page (the software told them so!). Another problem is that sometimes there's way too much data to fit into a query string. For instance, in MediaWiki you can move a page with all its subpages. There might be hundreds or even thousands of these, and a success/failure message is printed for each, with the reason for failure if appropriate. This might be too long to fit in a GET. Just stick the data into the query parameters, including the user's ID, then sign the query parameters, and when serving the page, check the signature and check the user's ID matches the cookie. Adding data to the URL makes sense in some scenarios, but not in others. Often the application needs to hold on to state shared by a sequence of pages in the same browsing context, but at the same time not wanting this state to be shared with the same set of pages in another browsing context. This rules out cookie-based state as this is shared by all browsing contexts in the user agent. With current technology a common solution is to add a unique id to the URL that points to a storage area on the server where the full state is stored. The same id is then used on all pages throughout the navigation sequence, and the id could be said to represent the browsing context (ie window or tab) as each browsing context will get a different id, mapping to state for that browsing context. For this scenario it would be better if the id parameter was not part of the URL, because: - the id parameter adds no meaning to the URL - the id parameter maps to an internal and transient data structure on the server and not to an entity - the above two bullets mean we don't want it in bookmarks - coming back with an old URL (with an old id) requires handling cases like recreating an expired data structure, or handling conflicts if our id is now allocated to another user A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the user takes several similar actions at once (e.g., moving a number of pages at once in multiple tabs). Using sessionStorage can be used to work around this somewhat, at least in AJAX apps. For server-oriented webapps a solution that doesn't rely on script is preferred. This means the server should be able to transmit browsing_context-scoped state to the client and have it automatically sent back on any following request. Something like browsing_context-oriented cookies. I'll include this in my state handling overview in the new thread. Best regards Mike Wilson
Re: [whatwg] page refresh and resubmitting POST state
On Fri, 22 May 2009, Mike Wilson wrote: I can see some usefulness for adding a couple of subjects to the HTML5 spec: - how browsers should handle page refresh, in particular for pages received through POST (= do you want to resubmit?) Done. - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) On Fri, 22 May 2009, Jonas Sicking wrote: This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. On Fri, 22 May 2009, Mike Wilson wrote: With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. On Sat, 23 May 2009, Kornel Lesinski wrote: As far as I understand the resubmit problem is just sign of poor implementation that violates SHOULD NOT in the HTTP RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 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.) On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. [...] Defining some support in the browser could replace or simplify parts of these solutions. I'm sure people are open to suggestions. I wouldn't worry about whether they're in scope for HTML5 or not; if they're not, we can always redirect you to the right group. On Sun, 24 May 2009, Aryeh Gregor wrote: The problem is that since HTTP is stateless, you don't have the data available to show a confirmation page. For instance, suppose a user on Wikipedia moves a page to a new name. That user is presented with a page saying You have successfully moved X to Y. If this confirmation page is the result of a POST, then trying to go back in the history (in Firefox, at least) will risk presenting the annoying Do you want to resubmit? dialog. But if you use a 303 (practically, 302), then how do you know what X and Y are in the new request? One workaround is to just stick the info in the query string of the GET. One problem with this is that it makes it easy to trick users into thinking they've just done something alarming: you can link to confirmmove.php?page1=Main_Pagepage2=Main_Page_ON_WHEELS, and the user will think they actually just moved the page (the software told them so!). Another problem is that sometimes there's way too much data to fit into a query string. For instance, in MediaWiki you can move a page with all its subpages. There might be hundreds or even thousands of these, and a success/failure message is printed for each, with the reason for failure if appropriate. This might be too long to fit in a GET. Just stick the data into the query parameters, including the user's ID, then sign the query parameters, and when serving the page, check the signature and check the user's ID matches the cookie. A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the user takes several similar actions at once (e.g., moving a number of pages at once in multiple tabs). Using sessionStorage can be used to work around this somewhat, at least in AJAX apps. On Sun, 24 May 2009, Kornel Lesinski wrote: 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). This would be something for the HTTP spec, I believe. HTML5 just mentions asking for reloads when the method is not idempotent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] page refresh and resubmitting POST state
On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. This would cause additional network round-trips which is suboptimal.
Re: [whatwg] page refresh and resubmitting POST state
I certainly want refresh to redo, for example, when validating a local document that I am editing. Chris
Re: [whatwg] page refresh and resubmitting POST state
Kristof Zelechovski wrote: I certainly want refresh to redo, for example, when validating a local document that I am editing. Chris What do you mean with editing a local document - is the document contents being edited inside an input field (f ex textarea) on a POSTing page? Mike
Re: [whatwg] page refresh and resubmitting POST state
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
Re: [whatwg] page refresh and resubmitting POST state
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
Re: [whatwg] page refresh and resubmitting POST state
On Sun, May 24, 2009 at 11:41 AM, Kornel Lesinski kor...@geekhood.net wrote: 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. In practice, that history can be kept for a long time. Even if the tab is closed, undo close tab still keeps the history. Even if the browser closes, the old session may be kept in newer browsers. But as long as it's kept for long enough that it's very rare to see the message, I don't think it's a big problem. 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. That does seem like a pretty good solution. Perhaps Mike Wilson can point out the problems with it. 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). When would that be?
Re: [whatwg] page refresh and resubmitting POST state
Aryeh Gregor wrote: You should spell out the existing problem carefully and in great detail, including existing solutions or workarounds, to get the best response. I certainly intend to do this once I get feedback on whether this subject is relevant for HTML5, or any other whatwg spec (preferrably from people involved in authoring these). Time is limited and I would like to only spend this effort if applicable to spec work. Looking at the current spec I haven't found any section that directly relates to this subject, that's why I'm asking if it is in the spec's scope to add a section about it. An observation though, is that the Web Storage text (that was previously in the HTML5 spec) discusses a client-side session to alleviate the problem of using cookies together with multiple windows/tabs: http://www.w3.org/TR/webstorage/#introduction The multi window vs cookie scenario is something I consider part of the page state problem space, but other parts of this problem space don't map well to web storage... I don't think refresh is a big deal. I've been using refresh/resubmit as an easy example so that everybody knows what I am talking about. The subject of page state handling has far greater implications than refresh, just like you show in your examples below. I've tried outlining it later in this post, but you might be able to contribute further info. .. The problem is that since HTTP is stateless, you don't have the data available to show a confirmation page. For instance, suppose a user .. Another workaround is to have a database table or memcached key or something that stores a move ID with the info, and put the move ID .. A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the .. Yet another workaround would be just to dispense with the confirmation page. For instance, when making a new post in a forum, the user could .. Yes, these are some of the workarounds I also had in mind which exemplify how web authors sometimes have to battle the page state handling in the browser. When/if this subject seems to relate to the HTML5 effort, I would like to contribute to a larger discussion on these kinds of topics. Best regards Mike
Re: [whatwg] page refresh and resubmitting POST state
Kornel Lesinski wrote: Is it possible for HTML 5 spec to say that browsers may re-send PUT without asking? It sounds like you are starting to agree with me that topics like these could deserve a place in the HTML5 spec :-) Aryeh Gregor wrote: On Sun, May 24, 2009 at 11:41 AM, Kornel Lesinski kor...@geekhood.net wrote: 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. That does seem like a pretty good solution. Perhaps Mike Wilson can point out the problems with it. In an earlier mail I was referring to this solution as conversation id in URL, and yes, there are drawbacks with this as well. Best regards Mike
Re: [whatwg] page refresh and resubmitting POST state
On Sun, 24 May 2009 17:40:21 +0100, Mike Wilson mike...@hotmail.com wrote: Aryeh Gregor wrote: You should spell out the existing problem carefully and in great detail, including existing solutions or workarounds, to get the best response. I certainly intend to do this once I get feedback on whether this subject is relevant for HTML5, or any other whatwg spec (preferrably from people involved in authoring these). Time is limited and I would like to only spend this effort if applicable to spec work. It depends what solution is chosen - browser behaviors and HTML elements/attributes are in scope of HTML 5, but HTTP methods and headers not so much. I don't think refresh is a big deal. I've been using refresh/resubmit as an easy example so that everybody knows what I am talking about. Hm, now I don't :) Can you re-state the problem you want to be solved? I thought you wanted to avoid browsers asking question whether they should re-submit POST. When/if this subject seems to relate to the HTML5 effort, I would like to contribute to a larger discussion on these kinds of topics. If the problem affects web applications and browsers, then that's probably good place to discuss it. -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Sat, May 23, 2009 at 4:29 AM, Mike Wilson mike...@hotmail.com wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Can you explain more in detail why PRG doesn't solve this problem? My understanding is that the do you want to resubmit UI comes up when sites *doesn't* use PRG, and the UI would disappear if they had used it. / Jonas
Re: [whatwg] page refresh and resubmitting POST state
Jonas Sicking wrote: On Sat, May 23, 2009 at 4:29 AM, Mike Wilson mike...@hotmail.com wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Can you explain more in detail why PRG doesn't solve this problem? My understanding is that the do you want to resubmit UI comes up when sites *doesn't* use PRG, and the UI would disappear if they had used it. PRG solves the immediate problem of getting rid of the resubmission dialog, but creates another problem: loss of page state. Sometimes this is not a problem, but often when you work with web applications, it is. So, an author will have to choose between two evils; either go with plain POST, which will keep the page state but cause resubmission questions, or go PRG which will eliminate the questions but lose page state. At first, the loss of page state in PRG may seem solvable by tucking a handle to that data inside the URL, but this scheme gets complex and breaks down when you want to separate multi-window operations (and are facing New Window in IE or Duplicate Tab in Chrome), or when you want bookmarkable URLs. There is a whole spectrum of possible improvements that could help out in these cases, but they all involve defining something about state. F ex, plain POST pages have to ask their question because they don't know if the page state they carry is harmless data needed only for telling the server what to display, or if it is something that will trigger an undoable action. Usually the page state is a mix of both these. So, one improvement could be making it possible to specify (per input element) if the state is for redisplay or for action. Then pressing Refresh could safely send the redisplay state without asking the resubmission question, and leave out the action state. (Assuming we want the semantics of the Refresh button to be Redisplay and not Redo.) At the other end of the spectrum we could help authors using PRG, to associate state with their GET pages without adding to the URL. This could f ex be solved by giving the server the possibility to associate some state with each page load (delivered in headers or body), which is then sent back to the server (in header) on any request that leaves that page, including page refresh. Web storage is touching on the same problem, mentioning the limitations of cookies, but AFAICT depends on script and has no transparent UA/server transfer. These are just examples of constructs that could be possible. I hope I have provided enough information to determine if this is indeed a subject that is relevant for HTML5. Best regards Mike
Re: [whatwg] page refresh and resubmitting POST state
I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Authors of Web Applications (the original name of the HTML5 spec ;-) are continuosly inventing new workarounds for this problem, all with different advantages and drawbacks, to achieve intuitive page handling when using a lot of POSTs. Examples of workarounds include PRG, flash scopes, conversation ids in URL, temporary cookie assignments, etc. Defining some support in the browser could replace or simplify parts of these solutions. But first I'd like to know if this subject is within scope of the spec. If it is, I could for starters imagine some prose about the UA asking the resubmit question on refresh of a page received through POST, as this is what current browsers do. Unless this is already covered by a referred spec, of course. Best regards Mike Kornel Lesinski wrote: As far as I understand the resubmit problem is just sign of poor implementation that violates SHOULD NOT in the HTTP RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 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.) -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Sat, 23 May 2009 12:29:56 +0100, Mike Wilson mike...@hotmail.com wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Browsers could make it possible by implementing history mechanism exactly like HTTP/1.1 specification suggests in section 13.13, i.e. going back in history should never cause resubmits, so there shouldn't be anything to ask about. Users should simply see previous state of the page, just like in case of GET. Do you think that solution suggested by RFC 2616 13.13 is not appropriate? Is Opera's solution of this problem not good enough? -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
Kornel Lesinski wrote: Do you think that solution suggested by RFC 2616 13.13 is not appropriate? It does not define what to do at page refresh, only history traversal, as far as I can see. Is Opera's solution of this problem not good enough? I think you are missing the point I am describing. I don't know if you develop Web Applications and are acquainted with the workarounds I've mentioned (conversation ids etc), but if you don't then it is probably hard to see my point ;-). Anyway, I respect your opinion that page refresh is enough well-defined by RFC 2616 and the Opera implementation, and doesn't need coverage in the HTML5 spec. Thanks Mike
Re: [whatwg] page refresh and resubmitting POST state
On Sat, 23 May 2009 15:38:02 +0100, Mike Wilson mike...@hotmail.com wrote: Do you think that solution suggested by RFC 2616 13.13 is not appropriate? It does not define what to do at page refresh, only history traversal, as far as I can see. Sorry, I've assumed you were talking about Back button only. In case of Refresh it depends whether user realizes implications of re-submitting. If browser designers don't believe that pressing Refresh button states intent clearly enough, then I think asking the question might be justified. As creator of application you can solve this dylemma: * 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. * If it's safe to resubmit, use PUT method (allowed in HTML 5), which is idempotent by definition. -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Fri, May 22, 2009 at 7:06 AM, Mike Wilson mike...@hotmail.com wrote: - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. Example: product.html contains a form method=POST action=addToCart.cgi. addToCart.cgi processes the parameters received from the POST request and replies with a 302 response with Location: displayCart.cgi. displayCart.cgi lists what is in the shopping cart. The result of this is that once the user submits the form on product.html, the UA will make a POST request to addToCart.cgi, then make a GET request to displayCart.cgi and display the result of that page. If the user refreshes the UA will again make a GET request to displayCart.cgi and display the result. / Jonas
Re: [whatwg] page refresh and resubmitting POST state
Thanks for expanding on my previous mail, Jonas, but I was assuming that everyone on this list was aware of the PRG pattern and its existing support in browsers. With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. Best regards Mike Jonas Sicking wrote: On Fri, May 22, 2009 at 7:06 AM, Mike Wilson mike...@hotmail.com wrote: - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. Example: product.html contains a form method=POST action=addToCart.cgi. addToCart.cgi processes the parameters received from the POST request and replies with a 302 response with Location: displayCart.cgi. displayCart.cgi lists what is in the shopping cart. The result of this is that once the user submits the form on product.html, the UA will make a POST request to addToCart.cgi, then make a GET request to displayCart.cgi and display the result of that page. If the user refreshes the UA will again make a GET request to displayCart.cgi and display the result. / Jonas
Re: [whatwg] page refresh and resubmitting POST state
On Fri, 22 May 2009 21:48:28 +0100, Mike Wilson mike...@hotmail.com wrote: Thanks for expanding on my previous mail, Jonas, but I was assuming that everyone on this list was aware of the PRG pattern and its existing support in browsers. With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. As far as I understand the resubmit problem is just sign of poor implementation that violates SHOULD NOT in the HTTP RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 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.) -- regards, Kornel Lesinski
