XML-RPC and http

Aaron Swartz aswartz@upclink.com
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
> no.

I looked. It uses POST for sign in (good), for creating a new 
account (good) and effectively GET (due to the complicated 
JavaScript) for the "Start a Blog" page, which you can see for 
yourself at:

http://www.blogger.com/blog_new.pyra


>> POST *is* the correct method to use for log in! Logging in is a
>> side-effect, no?
>
> 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
> string.

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
>> GET)
> 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 
you!).

>> ... 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:me@aaronsw.com>  |  <http://blogspace.com/about/>
<http://www.aaronsw.com/> |     weaving the two-way web