[hunchentoot-devel] PUT parameters missing?
I'm waaay behind in updating from 0.5.0, so yesterday I grabbed 0.11.1. I use a lot of PUT requests in my web app, and data is sent in parameters just like in POST. However, the latest version of hunchentoot does not appear to populate post-parameters in a PUT request. -- Jonathon McKitrick jmckitrick@reedlarkeygroup.com
On Mon, 4 Jun 2007 09:28:54 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
I'm waaay behind in updating from 0.5.0, so yesterday I grabbed 0.11.1. I use a lot of PUT requests in my web app, and data is sent in parameters just like in POST. However, the latest version of hunchentoot does not appear to populate post-parameters in a PUT request.
http://common-lisp.net/pipermail/tbnl-devel/2007-May/001360.html
On Jun 4, 2007, at 9:34 AM, Edi Weitz wrote:
On Mon, 4 Jun 2007 09:28:54 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
I'm waaay behind in updating from 0.5.0, so yesterday I grabbed 0.11.1. I use a lot of PUT requests in my web app, and data is sent in parameters just like in POST. However, the latest version of hunchentoot does not appear to populate post-parameters in a PUT request.
http://common-lisp.net/pipermail/tbnl-devel/2007-May/001360.html
I'm using REST as well, so maybe I can offer some thoughts on this. POST is used when sending data to a URL endpoint, and often it means an entity is created, like an SQL INSERT. PUT is used to update some properties of an already existing entity, like an SQL UPDATE. At least that's the most common use. So with a POST reply I create an entity and return the URL in the 'location' header of the response. A PUT request applies the parameters to the entity identified by the URL. -- Jonathon McKitrick jmckitrick@reedlarkeygroup.com
On Mon, 4 Jun 2007 09:48:19 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
I'm using REST as well, so maybe I can offer some thoughts on this. POST is used when sending data to a URL endpoint, and often it means an entity is created, like an SQL INSERT. PUT is used to update some properties of an already existing entity, like an SQL UPDATE. At least that's the most common use. So with a POST reply I create an entity and return the URL in the 'location' header of the response. A PUT request applies the parameters to the entity identified by the URL.
Strange. To me that seems counterintuitive and not really in sync with how PUT is described[1] in RFC 2616. But, anyway, if you REST guys think you need this, send a reasonable patch[2] and I'll review it. Cheers, Edi. [1] "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." [2] http://weitz.de/patches.html
On Jun 4, 2007, at 10:30 AM, Edi Weitz wrote:
On Mon, 4 Jun 2007 09:48:19 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
I'm using REST as well, so maybe I can offer some thoughts on this. POST is used when sending data to a URL endpoint, and often it means an entity is created, like an SQL INSERT. PUT is used to update some properties of an already existing entity, like an SQL UPDATE. At least that's the most common use. So with a POST reply I create an entity and return the URL in the 'location' header of the response. A PUT request applies the parameters to the entity identified by the URL.
Strange. To me that seems counterintuitive and not really in sync with how PUT is described[1] in RFC 2616. But, anyway, if you REST guys think you need this, send a reasonable patch[2] and I'll review it.
Since I just jumped from 0.5.0 to 0.11.1, do you remember where in that span you made the change to remove post-param support for PUT? I'll start diffing from there.... -- Jonathon McKitrick jmckitrick@reedlarkeygroup.com
On Mon, 4 Jun 2007 11:30:26 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
Since I just jumped from 0.5.0 to 0.11.1, do you remember where in that span you made the change to remove post-param support for PUT?
There never was official support for that, that's why they're called POST parameters. Maybe it worked by accident. Right now, there's a test in request.lisp which explicitely looks at the request method. ;; if the content-type is 'application/x-www-form-urlencoded' ;; or 'multipart/form-data', compute the post parameters from ;; the content body (when (eq (request-method request) :post) Now that I think of it, this should probably be replaced with some user-configurable variable which holds a list of methods where the default value is just the one-element list '(:post): (when (member (request-method request) *foo* :test #'eq)
On Jun 4, 2007, at 11:42 AM, Edi Weitz wrote:
On Mon, 4 Jun 2007 11:30:26 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
Since I just jumped from 0.5.0 to 0.11.1, do you remember where in that span you made the change to remove post-param support for PUT?
There never was official support for that, that's why they're called POST parameters. Maybe it worked by accident. Right now, there's a test in request.lisp which explicitely looks at the request method.
;; if the content-type is 'application/x-www-form- urlencoded' ;; or 'multipart/form-data', compute the post parameters from ;; the content body (when (eq (request-method request) :post)
Now that I think of it, this should probably be replaced with some user-configurable variable which holds a list of methods where the default value is just the one-element list '(:post):
(when (member (request-method request) *foo* :test #'eq)
I think that would do the trick nicely! -- Jonathon McKitrick jmckitrick@reedlarkeygroup.com
On Jun 4, 2007, at 10:30 AM, Edi Weitz wrote:
On Mon, 4 Jun 2007 09:48:19 -0400, Jonathon McKitrick <jmckitrick@reedlarkeygroup.com> wrote:
I'm using REST as well, so maybe I can offer some thoughts on this. POST is used when sending data to a URL endpoint, and often it means an entity is created, like an SQL INSERT. PUT is used to update some properties of an already existing entity, like an SQL UPDATE. At least that's the most common use. So with a POST reply I create an entity and return the URL in the 'location' header of the response. A PUT request applies the parameters to the entity identified by the URL.
Strange. To me that seems counterintuitive and not really in sync with how PUT is described[1] in RFC 2616. But, anyway, if you REST guys think you need this, send a reasonable patch[2] and I'll review it.
I've been testing some code to PUT an XML entity rather than populating the POST parameters, but I'm not sure how to get the content from the request via hunchentoot. I've found GET-CONTENT in CL-WEBDAV, but that code seems to read the raw content data as a file, while I'm sending data as an XML document. Is there a simple way to do this without resorting to another library? -- Jonathon McKitrick jmckitrick@reedlarkeygroup.com
On Sun, 2007-06-17 at 11:26 -0400, Jonathon McKitrick wrote:
[snip]
I've been testing some code to PUT an XML entity rather than populating the POST parameters, but I'm not sure how to get the content from the request via hunchentoot. I've found GET-CONTENT in CL-WEBDAV, but that code seems to read the raw content data as a file, while I'm sending data as an XML document. Is there a simple way to do this without resorting to another library?
Well - you need to implement a handler for the PUT method. Inside this handler you must read the content from the stream - have a look at 'raw-post-data' in 'hunchenoot/request.lisp', esp. the last sentence of the documentation: "... Note that this function is slightly misnamed because a client can send content even if the request method is not POST." HTH Ralf Mattes
-- Jonathon McKitrick jmckitrick@reedlarkeygroup.com
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sun, 17 Jun 2007 19:44:17 +0200, Ralf Mattes <rm@seid-online.de> wrote:
Well - you need to implement a handler for the PUT method. Inside this handler you must read the content from the stream - have a look at 'raw-post-data' in 'hunchenoot/request.lisp', esp. the last sentence of the documentation:
"... Note that this function is slightly misnamed because a client can send content even if the request method is not POST."
What Ralf said. Note specifically that RAW-POST-DATA is exported and that there's a keyword argument WANT-STREAM. (It is mentioned in the doc string, but I just noticed it's not show in the function's signature in the HTML documentation. This'll be fixed.)
participants (3)
-
Edi Weitz -
Jonathon McKitrick -
Ralf Mattes