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

[Ben Burnett]

Re: [Mailman-Developers] Re: GET vs POST (was Re:
subscription confirmations)
------- Original Copy -------
>Subject: Re: [Mailman-Developers] Re: GET vs POST (was Re:
subscription confirmations)
>Date: 07/18/2001 4:01 PM
>From: "Jay R. Ashworth" <jra@baylink.com>
>To: mailman-developers@python.org

>On Wed, Jul 18, 2001 at 12:51:28PM -0700, Chuq Von Rospach
wrote:
>> On 7/18/01 12:32 PM, "Jay R. Ashworth" <jra@baylink.com>
wrote:
>> > Alas, this is *just like* making the GET active, only
worse.
>> 
>> How? I'm confused. Either way, you end up at a page with
the confirmation
>> information and an "accept" button (or use whatever
terminology you want).
>> 
>> If you think that's wrong, what do you think would work?
I'm lost where
>> you're headed here.
>
>The two suggested approaches were, as I understood them, a
URL embedded
>in the mail with a GET that was active and actually *did*
the
>unsibscribe, and a URL embedded in the mail with a
"pseudo-GET"; that
>is, there is no "?", but the URL is *still* magic, and
performs the
>action when the URL is retrieved.

This is not the impression that I had I thought we were
discussing two different possibilities.

1) the way it is done now.
visit the link (inherently a get operation) and you are
unsubscribed (or subscribed as the case may be).  The page
that you see when you visit this link tells you that the
unsubscribe operation has been performed.

2) the way C3C wants it done.
visit the link (still a get operation) and you are taken to
a page where you have to submit a form in order to have the
unsubscribe operation performed.

>
>If I correctly understood your latter suggestion, then
that's even
>worse, because 'scoopers' can't even avoid it -- it's not
marked as
>'magic' by the "?" character in the URL.

It appears as though you might be mistaken as to what
constitutes a GET request.  Here is a multiple choice
question to make sure we are all on the same page.

Which of the following URLs is uses the GET method.
x. http://host.domain.com/script.cgi?param=value
y. http://host.domain.com/script.cgi
z. http://host.domain.com/script.cgi/pathinfo?id=12

a) x.
b) y.
c) z.
d) all of the above.
e) none of the above.
f) it depends on how the HTTP Client calls the url.

The way I understand it the answer is "f) it depends on how
the HTTP Client calls the url.".  Having a "?" character
does not determine wether a url will be called using GET or
POST or any other method.
Methods listed in RFC 2616 for HTTP 1.1 include OPTIONS,
GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT,
extension-method ( extension-method = token )
(see ftp://ftp.isi.edu/in-notes/rfc2616.txt  section 5.1.1
for more details on methods)

There are specifications on what each method is supposed to
be used for (indeed this is what were discussing), but there
is nothing to keep someone from misusing a method (as is
shown by Mailman's own ?mis?use.)  An interesting thing
about specifications is that their value decreases as the
number of infringements against them increases.  And their
value increases as the number of compliances increases.

As far as I know most (if not all) mail clients that allow
the user to visit a URL embedded in an email use the GET
method to fetch that URL.  But the only things keeping
someone from building an email client that used the POST
method are rfc 2616 and the wrath of Gerald and the W3C
army.

For what it's worth I like option 2.
- It requires the user to make a more definite step towards
subscribing/unsubscribing.
- it exposes "naive" users to more technological steps
without being overly confusing. (more exposure=good)
- it complies with the W3C spec.

As far as whether the specification in this instance is
good  or valuable.  I don't think it's a simple cut and
dried matter, and I'll give it some more thought and
hopefully .

- Ben