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