[Mailman-Users] Re: GET vs POST (was Re: subscription confirmations)

[Gerald Oskoboiny]

(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/Input

> Sure,
> 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 at impressive.net>
http://impressive.net/people/gerald/