- From: Jon Barnett <jonbarnett@gmail.com>
- Date: Mon, 12 Nov 2007 11:18:12 -0600
- To: "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: "Mark Baker" <distobj@acm.org>, "public-html@w3.org" <public-html@w3.org>
On Nov 8, 2007 5:50 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > The expectation is that unless you've typed in a credit card number you can > click _anything_ without fear, from what I've seen. Again, the difference > between GET and POST is just not something users know about (or much care). I'm > not sure they should need to, either... > Sorry if I'm beating a dead horse... (I'm just reiterating your point...) Users do indeed know the difference between a GET and a POST after the fact - when they press the refresh button or the back button. Browsers generally display a warning letting them know that this request contained POST data and it may not be safe to repeat the request because that data would be re-posted (credit card numbers and all). This is precisely why POST is appropriate for @ping. The browser shouldn't repeat the request without explicitly warning the user. The browser can still follow the destination link - it's a GET request, but it shouldn't automatically resend the ping request, because it's a POST and it may charge the advertiser money. The only method more appropriate would be a hypothetical unsafe method with better semantics and that doesn't allow a message body. But it would still have to be "unsafe". I'm don't understand the concerned discussion over it being a quiet (not silent) POST request because it doesn't have a body. If there's a concern over sending such a quiet POST request, then @ping should be disabled entirely (which should be an option). Even then, the concern has nothing to with the method of the request, but the existence of the request - you click one link one time and multiple requests happen. As long as that concern is dealt with, I don't understand the rest. -- Jon Barnett
Received on Monday, 12 November 2007 17:18:22 UTC