[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> On Thu, 31 Jul 2003 11:23:15 -0400, John Cowan
> <jcowan@reutershealth.com> wrote:
>
>> Norman Walsh scripsit:
>>
>>> What if the GET drops a can of coke on your desk?
>>
>>
>> Short of matter replication (Star Trek or Drexler varieties), it can't do
>> that. If the can is brought from somewhere else, that's a side effect,
>> and GETs have to be idempotent and therefore side-effect-free.
Idempotent and side-effect free are two different things. HTTP PUT and
DELETE are both idempotent, but definitely have side effects.
> Whoop! Whoop! Permathread warning ...
>
> Uhh, GET's are *supposed* to be side-effect free, but that's not
> enforced by anything I'm aware of in a typical HTTP implementation. I'm
> not at all sure that's true on the wild wild web, very definitely not in
> the case of pay-by-the-kilobyte wireless plans that have (well, "had"
> since I have an unlimited plan now) the side-effect of running up my
> cellphone bill every time I do a GET. Likewise, A little View Source
> expedition on Amazon.com shows a lot of "method=get" forms that seem to
> have what I would call side effects. (Fortunately, One-click ordering
> is not implemented with GET, but it *could* from a mechanical point of
> view, no?).
Note that the spec doesn't say that "GETs must be side effect free".
Instead, it says that GET and HEAD should be safe (see RFC 2616, section
9.1.1 [1]). In particular the last paragraph of that section says:
"Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in fact,
some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them."
The last sentence explains why it would be a bad idea for Amazon to
implement one-click ordering with GET (either method=GET forms or <A>
tags). Users (or software agents like spiders) shouldn't incur
obligations by clicking links or typing URIs into the browser.
ISP bandwidth fees seem like a different issue to me, both because they
are at a different protocol layer, and because they involve a third
party. Sam Ruby and Mark Baker discussed the issue of whether the Google
API's limit on number of queries per day meant that it should be using
POST rather than GET. See [2] and [3].
> So, I assert that there is no real-world software reason why clicking on
> a link could not result in a can of Coke being delivered to one's desk,
> although that would clearly be a Bad Thing in terms of the Webarch and
> the HTTP spec. Am I mistaken?
I guess it's alright for GET to deliver a Coke, as long as it doesn't
charge my account for it. And if the Googlebot spiders the Coke
machine's URL, it's under no obligation to pay for any Cokes dispensed.
Jim
[1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1
[2] - http://www.intertwingly.net/blog/784.html
[3] -
http://markbaker.blogspot.com/2002_09_01_markbaker_archive.html#81091743
|
