W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

Re: Extension methods & XMLHttpRequest

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
Message-ID: <20060615105732.GB24710@mail.shareable.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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:39 UTC