XML-RPC and http
Mon, 13 Aug 2001 08:58:04 -0500
On Tuesday, August 7, 2001, at 06:19 AM, Clay Shirky wrote:
>> In the examples of Blogger and iVillage you gave earlier you
>> claimed the issue was that they used POST to log in.
> Look again. Blogger uses POST for every form on the HP, idempotent or
I looked. It uses POST for sign in (good), for creating a new
account (good) and effectively GET (due to the complicated
>> POST *is* the correct method to use for log in! Logging in is a
>> side-effect, no?
> http is stateless, so logging in produces no side effect. Saying "Show
> me the present state of my in-box" is no more a side effect than
> saying "Show me the present state of a stock price."
Saying "show me the present state of my in-box" is not logging
in. Logging in is the process of asking the server to give you a
cookie, updating it's database of last-visited times, starting
the "stickiness counter" and placing your name on the page of
"Currently Active Users". These are all side-effects.
In most sites, once I'm logged in (via POST) I can GET my inbox
as many times as I want by hitting reload.
Similarly, why is Amazon's 1-Click ordering a POST? Because they
don't want folks to hit reload and reload and reload and end up
with 3 copies of the book shipped to their house. They don't
want Google or a caching proxy to automatically buy every book
in their collection.
Netscape had (has?) a little window that pops up when you reload
a POSTed page that warns you of the possible consequences.
Obviously, they'd never do that for GET.
> The reason MSFT, to take but one example, uses GET for stock quotes
> but POST for a Hotmail login has nothing do do with side effects and
> everything to do with POST not showing the passwd in the query
Cool! More examples of practicality and theory converging, just
like I've been claiming all along. You're less likely to want to
reveal data that has side-effects (i.e. allows the user to look
at your email) so you'll stick it in a POST.
>> I agree, it is not enforced by the HTTP implementation (i.e.
>> your web browser will still work if someone uses POST instead of
> Yep, a usage you yourself defend (except, for some reason, when its
> used by XML-RPC.)
I don't defend it. I admit it. The Web has worked out well
because most scripting environments make it easy to switch
between GET and POST interfaces. Look at all the CGI modules for
various scripting languages and you'll see. Folks are able to
use GET when it's appropriate with a minimum of changes (editing
one word in the HTML, probably a similar amount in the code).
While folks may not have always followed the GET and POST
distinction, there's enough incentive that the popular sites
will soon learn. My issue is that XML-RPC makes it *impossible*,
mind you, *impossible* to properly follow these standards (which
there are many good reasons for XML-RPC users to follow, mind
>> ... but as I've mentioned several times before its enforced by
>> Google, bookmarking, linking, caching, etc. -- all those good things
>> which are built upon the foundation of URIs.
> Nope. The semantics of *GET* are enforced by things like bookmarking
> and linking. The semantics of POST are not enforced by anything. This
> leaves us with the situation we have today, where POST is a general
> purpose tool.
Wait a sec, I just thought I heard you say above that folks use
POST to hide sensitive information, like passwords. And don't
forget, they use it to prevent accidental browser reloads (as in
the 1-Click example). Oh, and they use it to prevent search
engines from doing stuff (as in, say, "Click here to erase this
page" on a Wiki).
>> Aha, even your New York webmasters know when to use GET!
> Sure, they know when to use GET -- only when POST can't be used as the
> default. They use POST as a general purpose tool for getting data to
> the server. Just like XML-RPC does.
You contradict yourself! Above you said that the Hotmail people
used POST because they wanted to hide the password. What are you
trying to show?
>> Great! The browser itself is enforcing the restrictions of the
>> RFC. What's the big deal?
> No its not. The browser does nothing to make the use of POST
> contingent on producing side effects.
It doesn't? Look at the bookmarking, emailing links, reloading
pages, the Netscape POST warning window (see above), prefetching
pages, etc. How are these not actions of the browser to make
sure that POST and GET are used properly?
>> Your NYC web designers have made this choice easier: default to
>> POST, use GET when folks need to bookmark it. In doing so, they make
>> the right choices.
> So again: what's wrong with XML-RPC defaulting to POST?
Once again, the issue is not that it's a default. The issue is
that it isn't a choice.
"Aaron Swartz" | Blogspace
<mailto:firstname.lastname@example.org> | <http://blogspace.com/about/>
<http://www.aaronsw.com/> | weaving the two-way web