As far as I can tell, sending an actual HTTP PUT request to a Camping
app will never parse the params out of the request body - or am I
going nuts? This code seems to say only POST''s will parse the request
body:
elsif @method == "post" and \
e.CONTENT_TYPE == "application/x-www-form-urlencoded"
q.u(C.qsp(@in.read))
end
I looked for an easy spot to stick a test case, but didn''t come up
with one... can anyone else confirm that this is an issue?
--
Nathaniel Talbott
<:((><
On 9/28/07, Nathaniel Talbott <nathaniel at talbott.ws> wrote:> As far as I can tell, sending an actual HTTP PUT request to a Camping > app will never parse the params out of the request body - or am I > going nuts? This code seems to say only POST''s will parse the request > body: > > elsif @method == "post" and \ > e.CONTENT_TYPE == "application/x-www-form-urlencoded" > q.u(C.qsp(@in.read)) > endI honestly wouldn''t expect PUT (or any other HTTP actions other than GET, POST, and HEAD) to pass the input through a normal form-decoding step -- most of the time, the "payload" for a PUT is going to be XML, JSON, or even raw binary. Since browsers won''t do PUT, why build in support for what amounts to a browser-only MIME type (application/x-www-form-urlencoded)? -Lennon
On 9/28/07, Lennon Day-Reynolds <rcoder at gmail.com> wrote:> I honestly wouldn''t expect PUT (or any other HTTP actions other than > GET, POST, and HEAD) to pass the input through a normal > form-decoding step -- most of the time, the "payload" for a PUT is > going to be XML, JSON, or even raw binary. > > Since browsers won''t do PUT, why build in support for what amounts > to a browser-only MIME type (application/x-www-form-urlencoded)?It seems to me that most restful frameworks are assuming that you can PUT the same as you can POST, i.e. that other than the verb (and what you might do with it) the two will be treated the same. I actually ran in to this problem while mussing around with my little Camping testing framework, since I was assuming that doing a proper PUT would have the same affect as doing a simulated PUT using a special query parameter. But I was surprised to find out that I was wrong, and that things aren''t parsed as one would expect. Of course, there''s also the fact that while browsers don''t *currently* support form verbs besides POST, I''m hopeful that that may change eventually. So am I wrong in assuming that PUT and other non-GET verbs should support application/x-www-form-urlencoded, or is this something that should be made to behave more consistently? -- Nathaniel Talbott <:((><
On 9/28/07, Nathaniel Talbott <nathaniel at talbott.ws> wrote:> Of course, there''s also the fact that while browsers don''t *currently* > support form verbs besides POST, I''m hopeful that that may change > eventually.Even if browsers do start supporting PUT requests, I''d be somewhat shocked if they do use that MIME type since POST already handles that case. I''m curious what the specs say about the payload types for PUT... it''s been way too long since I read them. ~thomas
On 9/28/07, Nathaniel Talbott <nathaniel at talbott.ws> wrote:> It seems to me that most restful frameworks are assuming that you can > PUT the same as you can POST, i.e. that other than the verb (and what > you might do with it) the two will be treated the same.This is a horrible Rails-ism, in my opinion. PUT and POST are entirely different actions, and the weirdness that Rails uses to make one masquerade as the other is hardly a "convention."> I actually ran in to this problem while mussing around with my little > Camping testing framework, since I was assuming that doing a proper > PUT would have the same affect as doing a simulated PUT using a > special query parameter. But I was surprised to find out that I was > wrong, and that things aren''t parsed as one would expect. > > Of course, there''s also the fact that while browsers don''t *currently* > support form verbs besides POST, I''m hopeful that that may change > eventually.Sure, but in that case, they will likely be using PUT for direct file uploads (i.e., in place of ''type="file"'' inputs) not for structured form submission, unless some data-binding framework like XForms has been used to associate the form with a persistent data format.> So am I wrong in assuming that PUT and other non-GET verbs should > support application/x-www-form-urlencoded, or is this something that > should be made to behave more consistently?I don''t know that there''s any major disadvantage to having Camping attempt to parse the request body if a) the request was made using a non-GET verb and b) the MIME type for the request was set to ''application/x-www-form-urlencoded''. (Of course, it should fail gracefully if this parsing fails, as a poorly-implemented HTTP client might, for example, mis-match the MIME type and payload serialization format.)
2007/9/28, Nathaniel Talbott <nathaniel at talbott.ws>:> As far as I can tell, sending an actual HTTP PUT request to a Camping > app will never parse the params out of the request body - or am I > going nuts?No you aren''t at all. Actually, Camping is only a toy to quickly hack small apps together. I am highly skeptical that we''ll never be able to implement the 397K of the HTTP1.1 rfc into it''s 4K limitation but I would be happy if somebody does it :) In the mean time, it doesn''t mean that it can''t provide some facilities for extension. Actually, the initialize method is the biggest method in Camping and I remember _why talking about splitting it up. Concerning the PUT method, the rfc starts it''s description with the following terms : "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." (sec9.6). As I understand it, it is intended to store files under a specific URL, but who knows what an "entity" exactly is ? If I am right, a form is not really a file since it''s entries order are not strictly defined. At least, it rapidly becomes complex because the RFC doesn''t specifies a strict list of accepted verbs. From the standard ones, OPTION, GET, HEAD and TRACE should be "safe" and thus not accepting "post" data I guess and DELETE makes no sense with an entity attached but I didn''t find any MUST or SHOULD attached to that assertion. -- Cheers, zimbatm
On Fri, 2007-09-28 at 22:50 +0200, Jonas Pfenniger wrote:> 2007/9/28, Nathaniel Talbott <nathaniel at talbott.ws>: > > As far as I can tell, sending an actual HTTP PUT request to a Camping > > app will never parse the params out of the request body - or am I > > going nuts? > > No you aren''t at all. Actually, Camping is only a toy to quickly hack > small apps together. I am highly skeptical that we''ll never be able to > implement the 397K of the HTTP1.1 rfc into it''s 4K limitation but I > would be happy if somebody does it :) In the mean time, it doesn''t > mean that it can''t provide some facilities for extension. Actually, > the initialize method is the biggest method in Camping and I remember > _why talking about splitting it up. > > Concerning the PUT method, the rfc starts it''s description with the > following terms : "The PUT method requests that the enclosed entity be > stored under the supplied Request-URI." (sec9.6). As I understand it, > it is intended to store files under a specific URL, but who knows what > an "entity" exactly is ? If I am right, a form is not really a file > since it''s entries order are not strictly defined. At least, it > rapidly becomes complex because the RFC doesn''t specifies a strict > list of accepted verbs. From the standard ones, OPTION, GET, HEAD and > TRACE should be "safe" and thus not accepting "post" data I guess and > DELETE makes no sense with an entity attached but I didn''t find any > MUST or SHOULD attached to that assertion. >The entity is the requst body. It''s in the RFC. PUT does specify to store something -- there''s response codes for "We assigned a URI" (201 -- Created, with Location:) It''s very different than POST -- Far more semantic load than POST. I''m using PUT in Camping with no trouble -- XML body, doing CalDAV -- and it works well. But it''s totally different than POST, true. Aria -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/camping-list/attachments/20070928/e577f8cf/attachment-0001.bin
On Fri, Sep 28, 2007 at 03:22:23PM -0400, Nathaniel Talbott wrote:> As far as I can tell, sending an actual HTTP PUT request to a Camping > app will never parse the params out of the request body - or am I > going nuts? This code seems to say only POST''s will parse the request > body: > > elsif @method == "post" and \ > e.CONTENT_TYPE == "application/x-www-form-urlencoded" > q.u(C.qsp(@in.read)) > endThe @method == "post" test is a vestige of when Camping just parsed anything that was POSTed. I didn''t really think about it when I submitted the patch to test the Content-Type. AFAIK there''s no reason not to remove the method test altogether; use those bytes for something more useful. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/camping-list/attachments/20070928/d90429e5/attachment.bin
> The @method == "post" test is a vestige of when Camping just parsed > anything that was POSTed. I didn''t really think about it when I > submitted the patch to test the Content-Type. > > AFAIK there''s no reason not to remove the method test altogether; use > those bytes for something more useful.agreed. you can handle request body -> @input for any method except the ones that explicitly forbid request bodies (GET, HEAD, OPTIONS/TRACE?..), in one swoop. the MIME test must stay, of course. otherwise when you add support for other MIMEs using #service it silenty fails trying to parse JSON or whatever as QSVars..> _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list