2 ms·

Not after a post. If you change the form method to get, I believe this is the behavior. There are tons of good reasons to prefer this behavior, aside from just

by timr 5y ago

Not after a post. If you change the form method to get, I believe this is the behavior. There are tons of good reasons to prefer this behavior, aside from just avoiding duplicates. Think of login forms.

fuzzy2 5y ago
Yes, even after POST. Why not try it, right here, on Hacker News. The comment form uses POST. I post this comment and go back and my text is still in the input box. In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.
- deleted 5y ago
  [deleted]
- timr 5y ago
  Redirect after POST was a pattern created to bypass the warnings that (most) browsers emit on back-navigating after form submit, while still preventing double-submit (by redirecting to the GET): https://www.theserverside.com/news/1365146/Redirect-After-Post https://www.theserverside.com/news/1365146/Redirect-After-Po... It sounds like this warn-on-double-submit behavior is convention and not required, so maybe it has become more common for browsers to stop doing it. > Why not try it, right here, on Hacker News. OK, I did. HN does a 302 redirect on comment POST to the comment GET. When you back nav, you are seeing the response to a GET request to /reply?id=X (In other words, the form is re-rendered.) Edit: oddly, however, submitting on form rendered by GET /reply?id=X ends up creating a new comment, so that's just weird server logic. It might explain why you occasionally see duplicate comments on HN. Edit 2: on backnav to a comment edit, the redirect is to GET /edit?id=X, which is a re-render of the edit form, the process I described in my OP. Not sure what's going on with the back-after-post...maybe a bug?
  - fuzzy2 5y ago
    > When you back nav, you are seeing the response to a GET request to /reply?id=BLAH With the text you previously entered, which the browser restored. If it did not for you, you have non-standard settings like disabled caching. I can assure you that it behaves the same on Firefox for Linux, Windows, macOS and Safari on iOS: go back, form content is restored. In fact, the entire internet is full of people trying to get rid of this behavior.
    - timr 5y ago
      I don't have non-standard browser settings. I watched the form submit in the debugger. It responds with a 302 to the GET request.

by timr 5y ago

fuzzy2 5y ago

Yes, even after POST. Why not try it, right here, on Hacker News. The comment form uses POST. I post this comment and go back and my text is still in the input box. In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.

deleted 5y ago
[deleted]
timr 5y ago
Redirect after POST was a pattern created to bypass the warnings that (most) browsers emit on back-navigating after form submit, while still preventing double-submit (by redirecting to the GET): https://www.theserverside.com/news/1365146/Redirect-After-Post https://www.theserverside.com/news/1365146/Redirect-After-Po... It sounds like this warn-on-double-submit behavior is convention and not required, so maybe it has become more common for browsers to stop doing it. > Why not try it, right here, on Hacker News. OK, I did. HN does a 302 redirect on comment POST to the comment GET. When you back nav, you are seeing the response to a GET request to /reply?id=X (In other words, the form is re-rendered.) Edit: oddly, however, submitting on form rendered by GET /reply?id=X ends up creating a new comment, so that's just weird server logic. It might explain why you occasionally see duplicate comments on HN. Edit 2: on backnav to a comment edit, the redirect is to GET /edit?id=X, which is a re-render of the edit form, the process I described in my OP. Not sure what's going on with the back-after-post...maybe a bug?
- fuzzy2 5y ago
  > When you back nav, you are seeing the response to a GET request to /reply?id=BLAH With the text you previously entered, which the browser restored. If it did not for you, you have non-standard settings like disabled caching. I can assure you that it behaves the same on Firefox for Linux, Windows, macOS and Safari on iOS: go back, form content is restored. In fact, the entire internet is full of people trying to get rid of this behavior.
  - timr 5y ago
    I don't have non-standard browser settings. I watched the form submit in the debugger. It responds with a 302 to the GET request.