This project is archived and is in readonly mode.

#572 ✓resolved
specialunderwear

put request should be encoded

Reported by specialunderwear | January 26th, 2009 @ 12:56 AM | in 1.3.0 rc2 (closed)

when trying to send actual PUT requests instead of emulated ones, the data is mangled because the encoding header is not added. So POST and PUT should be treated the same.

See http://www.w3.org/TR/2006/WD-XML...

Comments and changes to this ticket

  • specialunderwear
  • Jan Kassens

    Jan Kassens January 26th, 2009 @ 07:17 AM

    • State changed from “new” to “open”
    • Assigned user changed from “Valerio” to “Jan Kassens”

    do you bave a testcase? php preferred..

  • specialunderwear

    specialunderwear January 26th, 2009 @ 09:39 PM

    Sorry no standalone test.

    The rationale behind the change is that if you are updating a resource on the server, by using a PUT request you are still sending a

    Content-type: application/x-www-form-urlencoded; charset=utf-8

    request body and the server needs to know that, if you want it to be extracted correctly.

    In my case I'm using ruby/mongrel and the http parser does not extract the request body properly if you are not adding the encoding header.

    So when you are sending something that is urlEncoded and you are doing a PUT, the header must be added. Same as with with POST.

  • gravydish (at gmail)

    gravydish (at gmail) February 2nd, 2009 @ 03:07 AM

    I've been trying for about 3 hours to get PHP (on Apache) to receive x-www-form-urlencoded arguments from MooTools.

    The best I can tell from sniffing outgoing traffic is that, without modification, MooTools 1.2.1 is sending the 'data' as a query string correctly.

    After adding the Content-type and Content-Length (as per user post in PHP documentation, http://www.php.net/manual/en/fea... headers, the PHP script still doesn't receive the data as it says it is supposed to.

    Also, according to much of the industry (http://www.apacheweek.com/featur..., see also php documentation link above), PUT is typically used for file uploads/replacements instead of page requests/processing.

    I think MooTools works as designed here and that using the emulation option allows for more seamless RESTful design without the hassle of varying definitions/interpretations of the HTTP methods.

    I have attached my test PHP script. Perhaps someone can enlighten me as to why it doesn't work.

    The script is receiving the PUT method request, and according to PHP documentation, PUT data should be received via STDIN; but this script never receives anything on STDIN.

  • specialunderwear

    specialunderwear February 2nd, 2009 @ 08:28 AM

    Hi I was also trying to get this to work on PHP. I tried to install pecl_http

    http://pecl.php.net/package/pecl...

    because HttpRequest (http://nl2.php.net/manual/en/cla... , which is in that package has a method getPutData (note that it also has getPutFile). I failed to install the extension so I couldn't give you a test case.

    Now if you look at the line of code which is changed in the patch, it consists of 2 parts.

    1. See if the option urlEncoded is true
    2. See if the request method is either POST or PUT

    It is true that PUT requests are used to update a file on the server. But the essense of the PUT method is not in that it is about about a file, but in that it UPDATES. The POST request is set when trying to create a new file on the server. The essence of post is that something new is CREATED. Back in the days all that happened over http was retrieving files and sending files. The current state of the web, that behind every url there is a dynamic app was not the case back then. That is why you will find in most documentation about PUT that it is used to update a file, because the documentation is old as hell.

    These days we DO have a dynamic application behind our urls and indeed, REST based webservices use method PUT to update a resource, and they use method POST to create a resource. The thing is that while I could very well manage to send all kinds of data in my request body, (I've send binary blobs in POST requests), most of the time I am simply sending url encoded form data. That is why mootools default for the option for urlEncoded is a very good one (it is set to true by default).

    What bothers me is that when I am doing the default thing, I am sending data urlEncoded, but with a PUT request, i suddenly have to monkey patch mootools to send the correct header. Much saner would be that if I want to do something NOT default, like sending a binary blob in my request body, I just pass the option urlEncoded: false and the header is not set.

    Now about the emulation part. The emulation is there because you can not set the method to PUT in a regular html form, the browser will just change it to it's default request method. So with REST based webservices it is a nescessary evil that when a resource is updated from a regular html form in a browser (and only in that case), some hacks are put in place to fake the protocol. With xmlHttpRequest you don't have to use any hacks because you can set the method to what you like and add headers if needed.

  • gravydish (at gmail)

    gravydish (at gmail) February 2nd, 2009 @ 04:38 PM

    I agree that the Content-type header should be added for (un-emulated) PUT requests by default in MooTools, since the data sent is already url-encoded by MooTools automatically anyway.

  • Jan Kassens

    Jan Kassens August 30th, 2010 @ 09:42 PM

    • Milestone changed from 2.0 to 1.3.0 rc2
    • Assigned user cleared.
    • Milestone order changed from “0” to “0”
  • Christoph Pojer

    Christoph Pojer September 4th, 2010 @ 11:06 AM

    • Assigned user set to “w00fz”
  • w00fz

    w00fz September 4th, 2010 @ 04:41 PM

    • State changed from “open” to “resolved”

    Fixed in 1.3.

    Cheers.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Attachments

Tags

Pages