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.

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-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?

> 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.

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.