37Signals and the Google Web Accelerator
So, the Google Web Accelerator prefetches links. Not a big surprise. Unless clicking on a link destroys or alters data and you can't figure out why your stuff is gone. This is not actually the web accelerators fault.
Now, good natured engineers worldwide are asking: "Why isn't POST good enough for you?"
Actually, some budding RESTafarians are not quite asking, they are calling you out, in their Napoleon Dynamite way, "Goll, using GET for non-idempotent requests. Idiot! Read RFC 2616, it's only like the sweetest RFC ever."
Ahem.
So, lots of web developer-types don't like POST for one simple reason: because they force you to use ugly form submission buttons. Ugly? We are engineers, if it's not ugly, it probably doesn't even work, right?
Visual aesthetics have again gotten in the way of clean engineering practices. Hell, at Blogger we even have some non-idempotent requests behind GET oursleves. So how do we keep things like the Google Web Accelerator, various web proxies, and all of the nasties out there from hurting us? We use JavaScript! But I don't mean just in onclicks, which stuff that doesn't speak JavaScript will ignore. You'll see lots of javascript:void(0) URIs floating around. See, if your hyperlink isn't a URI, there's nothing to fetch. If nothing gets fetched, nothing gets destroyed.
We know it's bad. We do it anyway. We just try to be, you know, savvy about it. Sorry this is so much trouble. It really is a big hassle, and it really is the browser's fault (yet again).
Think of it this way. It's dangerous; like pausing a running program, changing some of it's instructions, and resuming program execution. But if you couldn't do that then you would never be able to set a breakpoint in a debugger and then you would have to use printf or log4j for all of your debugging. Heh, I bet you do, anyway, don't you?
Hope that helps.
(If you think this tone is too personal, then that's becuase this is not written specifically to the 37Signals folks, who I think work hard and make neat stuff, it's actually written to you.)
posted by Steve Jenson at 1:23 AM
![[Atom Enabled]](http://saladwithsteve.com/valid-atom.png)
10 Comments:
And really, for any non-idempotent request we do with a GET, we should switch it to a POST, and can do so easily because we submit it with JavaScript.
But, this just proves that you can have links or table-cell buttons, or whatever you like, and still not incur the wrath of seemingly random state change.
4:12 AM
Yes, we *could* submit forms via JavaScript with POST but I wouldn't go so far as to say it's easy. You either build up a form dynaically with the DOM and submit it (possibly putting up a security dialog in the browser informing the user a POST is being sent and probably confusing the hell out of them), or you do it via XMLHTTPRequest and have to handle all the browser's regular error handling manually, not to mention make sure you send all the correct headers, cookies, and whatever else that the server is expecting.
No easy answers in web development. Not even the hacks.
11:24 AM
BOOGS!
Check out what we do with BlogThis!. We use Forms, they're POST, but submit them using javascript.
Why is it hard to use HTTP correctly and not make an ugly site?
6:14 PM
What browser and/or what security setting puts up a security dialog when you dynamically generate and post a form. I have never seen or heard of this before, and since it is a techique that I am very fond of I'd like to know. More research is required.
BTW, some utility classes can take away a lot of the chores of building up DOM forms.
8:06 AM
http://diveintoaccessibility.org/day_13_using_real_links.html
It takes two utopians to make everything impossible.
-Randy
3:00 PM
Would rel=nofollow work?
3:28 PM
You can CSS style a form method post submit button. So you're not truly stuck with the ugly submit button.
8:39 PM
I was just about to say what aidan r. said.
I realize the Web is a mess, and that it's hard to do things "right" all the time (depending on your considerations) but, all things being equal, I'm inclined to agree with Robert Sayre (in that there blog post you cited up there). I would try to architect my Web applications to use GET and POST as intended, at least as a baseline, and try to minimize fanciness or edge cases.
3:14 PM
This isn't really about idempotence. Idempotence just means an action has the same effect when performed more than once. It's perfectly possible for a delete link to be idempotent (i.e. if you click it more than once, the end result is still that you've deleted the object).
If you must use A tags for actions, for God's sake, don't use JavaScript to turn them into POSTs, that's just ugly. The easy and obvious solution is just to put a ? in your "dangerous" URLs. You probably don't even need a real query string; a ? tacked onto the end ought to work. I am pretty sure that Google Web Accelerator won't prefetch such URLs; no other prefetcher I've ever used does, and I've tried a few in my day. (Besides the fact that such URLs may cause undesired actions if prefetched, they also likely run scripts rather than retrieving static pages, so prefetching them has a high potential of significantly increasing server load, which would be unfriendly.)
11:08 AM
Jerry: that's an interesting point about appending a ? to the end of your URLs to keep prefetchers from working, I hadn't considered that.
I disagree on your definition of idempotence. If I try to delete the same resource N times then N-1 of those times should result in failure. I believe that idempotence is about lack of side-effects, not about always having the same side effects.
10:33 PM
Post a Comment
Links to this post:
Create a Link
<< Home