Friday, February 18, 2011

Day 23 - revisiting HTTP POST

So, now that the configuration is pretty much sorted out, comes the question of actually getting the data from the request. An easy way would be to take them as arguments of the GET. nginx automatically creates variables for the arguments: nginx arg_PARAMETER. But this is not very REST-like andd I want to be REST-like: POST to send the data and GET to retrieve the graph. So, I have to get the values from the POST. And, never before in my life I wondered how the POST variables get transferred from the client to the server. This has always been managed for me by the "other layers", would their name be Weblogic, JBoss, php or anything else. And I have always been happy like that. Now, I tried to go hardcore with nginx and it's time to start paying the price, I guess. So, I looked a bit on the web and found a few interesting things.

Point one. There is a nginx module that makes the POST arguments available as variables: the Http Form-input module. I could copy/paste from there. But the presence of a test on the Content-type and some logging messages got me wondering: what if it's not application/x-www-form-urlencoded? Or is it even possible? So, I went to the HTTP RFC to figure out what a web server SHOULD and MUST support in terms of ways to encode POST parameters in a request body. It doesn't help much. Reading a bit more got me a to a blog post that lists a few not so uncommon content-types: HTTP POST Content-Type.

Point two. Yes, a form can pretty much be submitted using any kind of Content-Type. But the common ones seem to be: application/x-www-form-urlencoded (this is pretty much putting the query part of the URL from a GET in the body of a POST request), multipart/form-data (a bit trickier but this is very similar to the multi-part encoding mechanisms used in emails and is described in RFC 2388. But text/plain seems to be possible as well.

So, I have yet another design decision to make: what should I support? First version will just support application/x-www-form-urlencoded like everybody else. I'll get multipart/form-data support later (if at all).

No comments:

Post a Comment