Mailing List Archive: Catalyst: Dev

Separate access to query string and body parameters

Index | Next | Previous | View Threaded

dan.kubbatautopilotmarketing.com

Aug 5, 2005, 10:52 AM

Post #1 of 6 (2012 views)
Permalink

Separate access to query string and body parameters

Marcus said I should post a message to the dev list about a possible
patch to Catalyst::Request (and the engines) that would add the ability
for you to access the query string parameters separately from any
parameters passed in with a POST request.

In addition to this I'd like to propose a second method that allows
access to the request body parameters separately.

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.

The query string parameters and the body parameters are so completely
different, they were never intended to be used interchangeably. When
they are, unintended things can happen. Like when Google's Web
Accelerator
assumed that it could fetch any URL with a GET and not have any
side effects. According to the RFC's their assumption was correct, but
they soon found out that a lot of web developers were using HTTP in
ways they aren't suppose to (like having deletion commands accessible
via a GET request).

Many frameworks don't make it easy enough to do the right thing and
some even encourage "broken" usage of HTTP. I'd like to make sure that
Catalyst doesn't prevent people from doing things according to the
RFCs should they wish to, while not placing any unnecessary burden on
developers who don't care either way.

Anyway.. thats my reasoning. Here's what I want to do:

I'd like to add two methods to C::Request called query and body
that work like this:

# query() -- for the query string

my @fields = $req->query;
my $value = $req->query($field);
my @values = $req->query($field);

$req->query($field => $value);
$req->query($field => @values);

# body() -- for the body data

my @fields = $req->body;
my $value = $req->body($field);
my @values = $req->body($field);

$req->body($field => $value);
$req->body($field => @values);

The param method will obviously need to continue to work, but it
could be made into a wrapper around the query and body methods
if you didn't want to have any duplication of data under the hood.
Otherwise I could just leave it alone -- although I'd vote for
wrapping.

For more uniformity with the existing API, a query_string and
body_data method could be added. They could just return hashrefs to
the underlying data, similar to how parameters and uploads work.

So what do you think? Are there any reasons you can think of that
this would be a bad idea?

Thanks,

Dan

sriatoook.de

Aug 5, 2005, 3:37 PM

Post #2 of 6 (1908 views)
Permalink

Separate access to query string and body parameters [In reply to]

Am 05.08.2005 um 10:55 schrieb Dan Kubb:
> So what do you think? Are there any reasons you can think of that
> this would be a bad idea?

I'm not against it, but the name "body" is already taken.

--
sebastian

dan.kubbatautopilotmarketing.com

Aug 5, 2005, 5:27 PM

Post #3 of 6 (1906 views)
Permalink

Separate access to query string and body parameters [In reply to]

>> So what do you think? Are there any reasons you can think of that
>> this would be a bad idea?
>
> I'm not against it, but the name "body" is already taken.

Hehe, about 20 seconds after I posted this Marcus pointed that out to
me. ;) I actually originally had the methods named as:

body_param
query_param

But I shortened them at the last second before hitting Send..

Dan

alexattaskforce-1.com

Aug 5, 2005, 7:26 PM

Post #4 of 6 (1910 views)
Permalink

Separate access to query string and body parameters [In reply to]

Hi Dan,

Me and Dan go back, way back :). Again good ideas and nice to hear from
you. I just had some comments for you below:

On Friday 05 August 2005 01:55, Dan Kubb wrote:
> Marcus said I should post a message to the dev list about a possible
> patch to Catalyst::Request (and the engines) that would add the ability
> for you to access the query string parameters separately from any
> parameters passed in with a POST request.

Sounds good, php does it too ( $_GET, $_POST, $_REQUEST ).

> 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...."

Here is some examples ( using google and keyword "blah", probably will wrap ):

#GET
http://web-sniffer.net/?url=http%3A%2F%2Fwww.google.ca%2Fsearch%3Fhl%3Den%26ie%3DISO-8859-1%26q%3Dblah%26btnG%3DGoogle%2BSearch%26meta%3D&submit=Submit&http=1.1&rawhtml=yes&gzip=yes&type=GET&ua=Mozilla%2F5.0+%28compatible%3B+Konqueror%2F3.4%3B+FreeBSD%29+KHTML%2F3.4.1+%28like+Gecko%29+Web-Sniffer%2F1.0.21

#POST
http://web-sniffer.net/?url=http%3A%2F%2Fwww.google.ca%2Fsearch%3Fhl%3Den%26ie%3DISO-8859-1%26q%3Dblah%26btnG%3DGoogle%2BSearch%26meta%3D&submit=Submit&http=1.1&rawhtml=yes&gzip=yes&type=POST&ua=Mozilla%2F5.0+%28compatible%3B+Konqueror%2F3.4%3B+FreeBSD%29+KHTML%2F3.4.1+%28like+Gecko%29+Web-Sniffer%2F1.0.21

> Many frameworks don't make it easy enough to do the right thing and
> some even encourage "broken" usage of HTTP. I'd like to make sure that
> Catalyst doesn't prevent people from doing things according to the
> RFCs should they wish to, while not placing any unnecessary burden on
> developers who don't care either way.
>
> Anyway.. thats my reasoning. Here's what I want to do:
>
> I'd like to add two methods to C::Request called query and body
> that work like this:

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.

>
> # query() -- for the query string
>
> my @fields = $req->query;
> my $value = $req->query($field);
> my @values = $req->query($field);
>
> $req->query($field => $value);
> $req->query($field => @values);
>
>
> # body() -- for the body data
>
> my @fields = $req->body;
> my $value = $req->body($field);
> my @values = $req->body($field);
>
> $req->body($field => $value);
> $req->body($field => @values);
>
> The param method will obviously need to continue to work, but it
> could be made into a wrapper around the query and body methods
> if you didn't want to have any duplication of data under the hood.
> Otherwise I could just leave it alone -- although I'd vote for
> wrapping.

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

Thanks.

>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev [at] lists
> http://lists.rawmode.org/mailman/listinfo/catalyst-dev

dan.kubbatautopilotmarketing.com

Aug 5, 2005, 10:30 PM

Post #5 of 6 (1917 views)
Permalink

Separate access to query string and body parameters [In reply to]

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

alexattaskforce-1.com

Aug 6, 2005, 2:20 AM

Post #6 of 6 (1918 views)
Permalink

Separate access to query string and body parameters [In reply to]

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.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads