(Chuq has suggested that we keep this thread on -developers, so this will be my last post to -users on the subject for now, I just wanted to respond to this here in case anyone else was curious about this stuff.)
On Tue, Jul 17, 2001 at 12:16:06AM -0400, Barry A. Warsaw wrote:
I have a couple of questions and comments, and then I /really/ need to get some sleep, so I'll follow up with more tomorrow.
If state changing GETs break the standards, then why does e.g. Apache by default allow you to GET a cgi program? Apache is the most common web server (certainly on Mailman-friendly OSes) so I would think that it should adhere to the specs pretty closely.
Aren't the majority of cgi programs of a state-changing nature?
I don't think so; TimBL addresses this in his writeup:
Forms: GET and POST
There is a very important distinction in society and in software, and
certainly on the Web, between reading and writing; between having no
effect and making changes; between observing and making a commitment.
This is fundamental in the Web and your web site must respect it.
Currently the line is often fuzzily drawn, which is very bad for many
reasons.
Form can work in two ways corresponding to this distinction.
One way is to direct the user, like a link, to a new resource, but one
whose URI is constructed from the form's field values. This is
typically how a query form works. (It uses HTTP's GET method.) The
user makes no commitment. Once he or she has followed the link, he or
she can bookmark the result of the query. Following any link to that
same URI will perform the same query again. It is as though Web space
were populated by lots of virtual pages, one for the results of each
possible query to the server. There is no commitment by the user. The
operation can be undone simply by pressing the Back button on a
browser. The user can never be held responsible for anything which was
done using HTTP GET. If your website fills a shopping cart as a user
follows normal links, and sometimes users end up ordering too much or
too little as they use a web accelerator or a cache, then it is your
fault. You should have used the second way.
The second way a form can work is to take a command, or commitment,
from the user. This is done using HTTP POST or sometimes by sending an
message. "Submit this order", and "unsubscribe from this list" are
classic examples. It is really important that the user understands
when a commitment or change is being made and when it isn't.
Hopefully, clients will help by changing the cursor to a special one
when a commitment is about to be made. Such an operation, like sending
an email, or signing and mailing a paper document, cannot be undone.
It is socially quite different. Browsers and servers and proxies which
understand HTTP treat it quite differently. You should never confuse
these two types of interaction on your web site, either way. If you
do, you break the web, and the web will break your site.
-- http://www.w3.org/Provider/Style/InputSure, you've got your odd search interface, but even a script like Mailman's private.py changes state: you get authenticated and a cookie gets dropped, and now your interactions are governed by a change in state.
private.py uses POST, no?
un: gerald> grep -i '<form' /home/mailman/Mailman/Cgi/private.py
<FORM METHOD=POST ACTION="%(basepath)s/">(from the 2.0.5 codebase)
I'll also mention that it seems to me that strict adherence to this rule would be pretty harmful to a platform like Zope, where urls are really encoded object access and execution commands (like RPC via urls).
I haven't studied Zope, so I don't know about that, sorry.
-- Gerald Oskoboiny <gerald@impressive.net> http://impressive.net/people/gerald/