- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 15 Jun 2006 11:57:32 +0100
- To: "S. Mike Dierken" <dierken@gmail.com>
- Cc: "'David Morris'" <dwm@xpasc.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, ietf-http-wg@w3.org
S. Mike Dierken wrote: > If you need to use POST and you want to ease the user experience in the face > of resubmitting the request, then script trickery works as an enhancement > but is not a general solution. Which isn't a big deal for nearly all web > (page) applications. This is all very abstract. It's quite clear how it makes sense to traditional documented-oriented or page-oriented web sites, with feedback through traditional forms. But for highly interactive sites, with lots of site-created "widgets" on the page, where the client sends a stream of messages to the server, and the server sends a stream of messages to the client, there are practical technical reasons why people are having to us GET when POST should be used in theory, and using POST when GET should be used in theory. If it's mandated that, say, a POST initiated by XMLHttpRequest will only succeed in response to a "user interaction", it really ought to be defined what that means, because if that means "only accepted if there was a mouse click or keyboard event triggering the script" or something like that, people writing those sort of sites will just carry on using GET for state-changing requests if that gives the desired behavior in practice. Here's an example: a site sends a page to the client, designed to "gracefully degrade" to reasonable HTML on less capable clients. The script on that page checks the client's features, decides it can enable fancy asynchronous messaging functions on that page, and then sends an iframe GET to update the state associated with this session and initiate the receipt of messages. That GET must not involve user interaction - it's behind the scenes to get the interactive bits of the page working after the page has loaded. It's probably idempotent but only the site author knows whether it is. And it should be a POST in theory, because it's causing a state change on the server and it's not fetching a resource or overwriting a resource. But it's a GET in practice, because that works. -- Jamie
Received on Thursday, 15 June 2006 10:57:38 UTC