[Catalyst-dev] Separate access to query string and body parameters

[Alex Pavlovic]

Hi,

On Friday 05 August 2005 13:32, Dan Kubb wrote:
> However, due to limitations in this format most modern web browsers
> can also send a POST request body with a Content-Type of 
> "multipart/form-data", which encodes each parameter 
> in its own MIME part.   It allows more rich information to be
> transmitted than a simple key/value pairing can, like binary data, and it is 
> formatted quite differently from key/value pairing.

Very true. Different encoding types will alter the underlying structure.

> Even still user agent's aren't restricted to sending things using
> those two Content-Types though in a POST request.  For example, a user agent
> could send a YAML string as "text/x-yaml" or XML as "text/xml" in either a 
> POST or a PUT request.

Sure, there are gaziliions of types :).

> You can even PUT/POST to a URI that has a query string.  *This* is
> one of the reasons I wanted the separation, since if I POST with a parameter
> that is the same name as a parameter in my query string, there will be a
> "collision" of the values.  In this case they will both get merged in as a 
> param and I won't be able to tell differentiate them without parsing the URI 
> myself. 

I think what you are looking for is a way to distinguish whether a request 
parameter was either a part of "Request-URI" or actual message body and then 
stuff the paramater into appropriate place so you can examine this 
afterwards. Sorry maybe I misunderstood the first time.

But I am starting to wonder why would someone send this in both
"Request-URI" and the message body ? And how would you prefer
one value over the other ( i.e. "body" vs "query" ) ?. I guess it all
boils down to the application specifics.

> I actually do POSTs to URI's with query strings very frequently,
> and with a good reason -- it solves one specific (common) problem
> beautifully.  

Allows you to keep everything uniform ? Makes backward compatibility
a thing of the past ? ... ( If you want you can email me off the list ) It can 
be dangerous road as well, since Request-URI may be too long for the server 
to handle.

> I actually think better names would be:  body_param and query_param.
>
> The reason for not using get() or post() is that any POST request can
> be to a URI that has a query string, and I thought it would be weird
> for the user to be handling a POST and have to use the get() method to
> look at the values of the query string.  

Well, he did issue "POST" in the first place didn't he ? Just kidding :) 

> Plus there are a dozen other HTTP methods that can use a request body, not 
> just a POST.  

You are right in that there are number of other methods ( actually not that 
many ) defined by HTTP/1.1. 

> Having to create names for each of those methods to access the exact same 
> thing (the body parameters) would be overkill probably. 

I guess you can always check the request method name and then extract the 
paramaters accordingly. 


Thanks.