Re: Separating GET and POST parameters

Jeremy Morton writes:
 > No way.  I think there's some reasonable arguments for seperating them out;
 > they are designed for different purposes.
 > 
 > Examples:
 > I might want to prevent someone from submitting their password via GET (less
 > secure).
 > I might want to prevent someone from submitting binary data via GET (very
 > likely to be invalid).
 > I might want to prevent someone from submitting a repeatable query (say, to
 > a search engine) via POST (not bookmarkable).

Generally speaking, the three example scenarios above can all be
handled by simply rejecting requests of the wrong type. Something
like:

<%init>
  if ( $r->method ne 'POST' ) {
    $m->redirect ( 'complain_about_method' );
  }
</%init>

I agree with Jon's argument that conceptual simplicity, ease of
maintenance, and portability all argue for treating GET and POST
arguments in the same way at the framework level.

This abstraction does prevent you from using URL query strings to make
POST requests, but there's no reason to ever do that. ("No reason to
ever design a system in that way," I should say. If you're trying to
port or maintain URI-compatibility with an older system that relies
such requests, then sub-classing the parts of the Mason core that glom
together GET and POST arguments is likely to be the least of your
problems <laugh>.)

Kwin


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click