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