[Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations)
Jay R. Ashworth
Thu, 19 Jul 2001 00:41:20 -0400
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
> >> On 7/18/01 12:32 PM, "Jay R. Ashworth" <email@example.com>
> >> > Alas, this is *just like* making the GET active, only
> >> 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.
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
> 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
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
> - 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
If we agree to ignore that category, then the whole argument is moot.
Jay R. Ashworth firstname.lastname@example.org
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