Keith Devens .com

Testing PRG

Testing a small change to my comment posting. I might as well explain what it is:

Using the POST-redirect-GET pattern (PRG) for web forms means that after a POST form submission, you then do a redirect so that the POST "goes away". By "goes away" I mean that if you hit refresh or go back and forward in your browser history it won't ask you to re-submit form data. This protects against duplicate POSTs and helps to prevent annoying the "user".

In addition, consider the case of my weblog comments. Unlike some weblog systems, the form to post comments is right on the weblog entry page itself. If you don't do a PRG then a person will not be able to refresh the page to see if anyone's responded to his comment without getting the POST resubmit popup. This is how it was on my site for a long time, and the only way around this was to navigate off the page and then navigate back to it. This is extremely inconvenient. So, I implemented PRG in my Formation library and then on my site.

The problem was this: the result of POST requests is never cached, so if you do a POST you'll always get fresh data. But, GET requests can be cached, so if your caching is set up a certain way you can do a POST to add a new comment, but then when you're redirected as part of the PRG you won't see the comment you just left. To get around this I added a kludge so that when you left a comment you were redirected back to the same page, except with "?newcomment=$comment_id" appended onto the URL. This is probably one of these cache busting techniques. That way, you'd be requesting a "new" page every time and be guaranteed to see fresh data.

At some point recently I've removed all caching headers from my site because I couldn't come up with a good caching scheme. Some of the things that made it hard for me to figure out the right caching scheme was that because my pages are mostly static I'd want them to have a pretty generous caching scheme, possibly even "public", but then if a new comment was posted people might not see it (in either the "recent comments" section on the right, as an increment to the comment count under a post, or as a new comment displayed on individual entry page). In addition, when I'm logged in to my site as an administrator, next to every post I get a little edit button that lets me easily edit that post. If I had very generous (like public) caching set up, after I logged in I'd have to do a "hard refresh" of the page contents to make the edit button show up.

I expected to go back and figure out the most appropriate scheme later, but it turns out the browser's default caching seems to behave exactly how I want it to. Back and forward don't cause the page to be refetched, so you get some of the benefits of caching, but when you navigate around it fetches a new page, so my edit buttons show up. There's even the case where you start typing in a textarea, go to another page, and then come back, and the text you typed is still filled in. With a stringent caching scheme (like no-store, no-cache, must-revalidate), that text would be wiped, but with the default caching scheme it's not. (Update: oops, I was wrong, it is wiped. However, I don't think you can have it both ways. i.e. have text not be wiped and have the behavior I describe next regarding my weblog entry form.) This also applies to my weblog entry form I'm typing in. With generous caching, if I edited an entry, saved it, and then went to edit it again, I'd get the entry as it was before I last edited it. If I made a change to the entry the second time the first change's changes would be overwritten. To get around this I'd have make sure to do a hard refresh on the weblog entry screen when re-editing posts, but with the default caching scheme this isn't a problem.

Anyway this post is here for me to do a test to see if I still need that "?newcomment=$comment_id" kludge to have new comments show up after you post them and you're redirected.

Update: And it works in both Internet Explorer and Firefox, but Opera seems to have issues. In fact, Opera is leaving the connection open even after it says "Completed request to keithdevens.com" in the status bar and is not refreshing the page. It's strange.

Update: I have no clue what Opera is doing. It seems to just be inexplicably leaving the connection open. If I preview (which doesn't do the redirect after post) and then post the comment it doesn't have the problem. Oh well, screw Opera. Incidentally, Opera uses weird headers I've never heard of, like Cookie2 and TE.

Permalink | 14 Comments | Tags: Programming, This website | id 5345

05:25 (utc-4)
edited: 06:02 (utc-4)