[Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations)
Tue, 17 Jul 2001 23:50:33 -0700
On Tue, 17 Jul 2001 21:08:59 -0400 firstname.lastname@example.org (Barry A. Warsaw) wrote:
>I was pulled away on other work for most of the day, but I think I've
>caught up with the whole thread.
>On the micro-issue of what Mailman's ttw confirmation should do, I am
>much more swayed by Thomas's observation that we can actually add
>useful value by providing a form that allows the user to confirm or
>discard his request. Given that I agree with everything Chuq et al
>have said about the inherent insecurity of GET, that seemed to me a
>more persuasive argument as it pertains narrowly to Mailman.
>Unless someone wants to volunteer to do usability studies (for which I
>don't have the time), I propose to change confirm.py to POST a form,
>and to pull in the ability to cancel held postings and subscription
>requests. Good idea Thomas.
>But I definitely appreciate the discussions Gerald initiated, and I'm
>glad he did that. Hopefully, Gerald can bring the very valid concerns
>raised here before the W3C and the standards authors. I think they're
>vitally important to where the web is going. The security and privacy
>and Java vulnerabilities (and the increasing number of sites that are
>simply unnavigatable without them), client-side trojans, web bugs,
>hijacked ActiveX certificates etc. etc. I really wish browser vendors
>would err on the side of security and privacy than on convenience.
>Sucker the user in enough times, or sucker enough of them in and the
>web will not be able to recover.
This whole controversy might be my fault -- I don't know the
pedigree of Barry's implementation, but I'd submitted a
confirm-by-visiting-this-URL patch several months ago. Hey, what
can I say? it was a quick hack. But since it was implemented I
don't think I've had one I-can't-follow-the-instructions-to-confirm
exchange with a cluefully-challenged proto-subscriber; neither have
I had a single complaint about misuse of GET.
The discussion has been thought-provoking. I'm not entirely swayed
to the position that it's morally wrong to use GET in this case,
where repeating the GET doesn't have any effect beyond what was
caused by the first. But Barry has a good point, that Thomas' idea
adds value. IMHO it's a much better UI -- no matter how much text
surrounds it, a URL in email isn't as clearly delineated as a big
fat button in the middle of a web page. Having a "don't confirm"
button also is even better. And regardless, using POST instead of
GET is a fairly simple change. From a pragmatic point of view,
there's not much reason not to comply with the published standard,
even if its justification is weak. (This is not to devalue the
discussion and debate of the W3C's position.)