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

[Dan Kubb]

Hi Alex,

> Me and Dan go back, way back :).

Wow, its good to hear from you.. hope you are doing well.

>> The reason for this is to keep the meaning between the two pieces
>> of information separate.  One is part of the URI -- the unique
>> identifier of a resource on the web -- and the other is metadata
>> for a request operation performed on a resource.
>
> True at the higher conceptual level, although at the lower request  
> level
> both "POST" and "GET" request types result in fields that are in
> the form of "key1=value1&key2=value2...."

When speaking about web browsers only they can appear similar in  
structure,
but they are not the same thing, not even at the HTTP protocol  
level.  When
speaking about ALL user agents, and the RFC's definition, they can be  
so far
apart to not appear similar in any respect.

A POST with a request body that has a Content-Type of "application/x- 
www-form-urlencoded"
will result in the key/value pairing similar to a GET form submission  
by a web
browser, like you mention.

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.

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.

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 actually do POSTs to URI's with query strings very frequently,
and with a good reason -- it solves one specific (common) problem
beautifully.  If anyone's curious I can outline why, but I didn't want
to muddle the conversation with application specific information.

> You meant "Catalyst::Request" right ? Why not name methods something
> like "get" and "post". I don't think those are used currently. You
> could also expand this and add methods for other request types.

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.  Plus there are a dozen other
HTTP methods that can use a request body, not just a POST.  Having to
create names for each of those methods to access the exact same thing
(the body parameters) would be overkill probably.

> Wrapping and combining sources is probably a good idea. Again
> this is "Catalyst" and the "DRY" concept.

Right, my thoughts exactly.

Thanks,

Dan