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

[Jay R. Ashworth]

My apologies that this is ugly; I'll try to clarify all my assertions
here to avoid wasting bandwidth.

On Wed, Jul 18, 2001 at 02:35:28PM -0700, Ben Burnett wrote:
> >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.

This is the way it's done based on either someone's patch (yours?), or
some other similar code; someone else asserts that this violates the
W3C recommendations, even though Chuq initiall preferred it (although
he appears to have changed his mind).

> 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.

Indeed.

But then, someone suggested a third option: effectively the same as 2),
but with the parameter hidden in a long URL, rather than sent as an
explicit GET parameter (blah.cgi?tag=heresmytag).

> >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.

Perhaps I'm mistaken, and a POST *can* be called with a ? parameter,
but in general, if you see a ?, the call will be the default GET, and
if the page is sending parameters as a POST, then they'll be sent "out
of band" to the URL, and the method will be POST instead of GET.

> 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.

All those things stipulated.  And perhaps I was making some unclear
assumptions in my phrasing.  But while all requests are GETs, unless
specifically otherwise arranged, what I meant to imply was
"parameterized GET's of CGI scripts".

Granted, the *client* can't tell explicitly if that condition is being
met without special knowledge... but the *system* designer certainly
knows; it's a closed system in this case.  (Or at least, semi-closed;
obviously you *can* call a CGI from something other than it's matched
form...)

> 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.

Indeed.  But such clients don't *currently* exist, which is more
pertinent to the issue at hand.

> 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 .

Indeed...  That clause no verb.  :-)

I was going on Chuq's assertion that in some cases, it's *necessary*
for merely clicking the link in an email to automagically perform the
unsubscribe... which was backed up by my own marketling-list and PHB
experience.

If we agree to ignore that category, then the whole argument is moot.

Cheers,
- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows
     -- Simon Slavin in a.f.c