subscription confirmations (was Re: [Mailman-Users] [ANNOUNCE] Mailman 2.1 alpha 2)

[Gerald Oskoboiny]

On Fri, Jul 13, 2001 at 02:03:51PM -0700, Chuq Von Rospach wrote:
> On 7/13/01 1:43 PM, "Gerald Oskoboiny" <gerald at impressive.net> wrote:
> 
> > This violates the HTTP protocol: visiting a URL (i.e., an HTTP GET)
> > should not have side effects like confirming a subscription.
> 
> My first reaction was "say what?" but I went and read the w3 stuff before
> responding...

Note that "the w3 stuff" includes the standards-track RFC 2616
(HTTP/1.1), the HTML 4.01 specification, and supplementary notes
by the creator of the HTTP protocol (incl its GET and POST methods);
they're not just a few random pages on w3.org :)

> > I realize that a number of other sites misuse GET this way, but I
> > think most of the large ones (e.g., Yahoo, online brokerages and
> > banks, etc.) get it right, and I think Mailman should too.
> 
> Because, frankly, I think w3 is wrong IN THIS CASE. That may make sense in a
> general case, especially on an HTTP only situation, but in this case, where
> the URL is being carried in e-mail to confirm an action the user has
> (presumably) started, I think they're wrong.

A couple of the references I gave in my previous message included
this specific example (confirming a subscription) as a case where
POST should be used instead of GET, so I think it is quite clear
that the specs do apply in this specific case.

Regarding "I think they're wrong", I respect your opinion, but
the HTTP spec is the result of a decade of work on and experience
with HTTP by full-time web protocol geeks...

> As long as the e-mail clearly
> delineates the action being taken, do what's easy for the user; and the user
> isn't going to want to go clicking through multiple links just to allow us
> to abide to the HTTP stuff.

What if I have a smart system on my desktop PC that is configured
to prefetch any URLs it sees in my incoming email, so there is
zero latency when I go to read them later? (or so I can read them
while offline, on a train or plane or something)

That would allow anyone in the world to sign me up for any
mailman-backed mailing list, whether or not I even see the email
confirmation requests. And that would be Mailman's fault, for
misusing HTTP GETs.

> But the key is this is a finalization of a distributed transaction, with
> e-mail distributing the token. Under other circumstances, I see W3's logic.
> Here, however, using a URL to bring up a page that says "click here to
> confirm" is only going to piss off Joe User, not make his life better.

I disagree: a large part of the reason for the distinction
between GET and POST is a social/usability one: people should
become accustomed to following hypertext links and clicking on
URLs without any action being taken. (personally, I cut and paste
URLs into my browser all the time without checking carefully what
they appear to be first, so when I actually want to read what's
there, I don't have to wait for the browser. Of course, I only do
that because I don't have that prefetching thing set up... yet.)

btw, part of the reason I care about this is that I work for W3C
and am currently evaluating mailman for use on lists.w3.org (to
replace smartlist) and we're pretty fussy about complying with
our own specs, for obvious reasons. But I'd be making this
argument whether or not that were the case, since it's clearly
the Right Thing to do imho...

-- 
Gerald Oskoboiny <gerald at impressive.net>
http://impressive.net/people/gerald/