XML-RPC and http
Mon, 6 Aug 2001 22:18:45 -0400 (EDT)
> Hmm, perhaps I should have said, "I have no problem with that
> when it's in line with how POST is specified in the spec".
Too late. In a moment of weakness, you told the truth: POST is widely
used as a catch-all form submission tool, without regard to its side
> > If it is acceptable to use POST whether or not there is a side effect,
> > than it seems to me XML-RPC is perfectly well within the context of
> > http methods, nu?
> It's doable, but not acceptable among the Web community...
Nonsense. The "Web Community" plainly has no compunction about using
POST as a general tool, viz the examples of Blogger, iVillage, etc
posted earlier, and your own defense of the use of POST even where it
produces no side effects.
> It's somewhere in betweeen a MUST and a REALLY SHOULD.
This is the writing of a desperate man. How, pray tell, could such a
thing possibly be enforced among the millions of non-engineers who
actually build web sites?
I did a little test a couple of weeks ago of your and Mark's
hypothesis that there is a robust and clear distinction between the
meaning of GET and POST, a distinction which is both well understood
and widely observed among your beloved "Web Community", and let me
tell you, the results will dismay you.
On the WWWAC list, the thousands-strong mailing list of NYC's web
design and production community and the virtual water cooler for every
web shop in the city, I asked "How do you decide when to use GET and
when POST for forms?"
The fifteen or so answers I got varied a bit, but the general
consensus was "Always use POST, unless you specifically want the
results to be bookmarkable." The reasons given for using POST as the
default included not showing the data on the command line, not
revealing hidden form fields, and not running into arbitrary command
Do you understand that? Among a group of serious working
professionals, people who have built a passel of web sites, all the
reasoning -- all -- was based on the artifact hermeneutics of the
browser. Not one person -- not one -- suggested that POST should be
used only when there were side effects. Not one person suggested that
GET and POST should be kept semantically separate. The idea of
consulting an RFC was never so much as mentioned; RFC might as well
have meant Rhode Island Fried Chicken for the purposes of this
The weakness of your and Mark's position vis-a-vis the semantic
clarity of existing methods is that rigor is incompatible with mass
adoption. As we have seen with effects like the death of the /P tag,
there _is_ no space between MUST and REALLY SHOULD. A distinction is
either enforced by the software or it is not, and distinctions not
enforced by the software die out.
GET is enforced by clickability and bookmarkability; POST is enforced
by nothing, and as we have seen (and as even you are willing to admit,
when you are not trying to weasel out of telling the truth) it has
accordingly become a general purpose tool for passing data to the