CSP spec

[Martin Hunt]

I'm having some trouble with the CSP spec (not sure if this is the correct place for discussion).  I think we should add a few things on Content-Type for POST's.  I'd be happy to write up the details, but I think there are a few things that need discussion first.  

A few details on the current implementation in js.io first: form posting turns out to be very strange stuff.  I could only avoid a preflight OPTIONS request in FF3.5 by transferring with Content-Type "text/plain" which seems to be ignored by the server anyway, but to send key/value paired data over the wire, I ended up using standard form encoding anyway.  The server blew up, which is to say it wasn't expecting form-encoded data - in fact, it wasn't expecting a URI encoded string at all.  Apparently it's coded to convert the entire POST body to the request data (for the handshake, this is params.d I guess).  So I patched the server to decode the data from the POST body if the body is present and use that as the request parameters.  Probably it should actually merge the URI params with the POST body params for maximal flexibility.

(Alternatively, the params could always come from the URI and the POST body could provide the data only... which might be what the original server implementation was trying to accomplish?  The CSP spec clearly indicates that key-value pairs should be sent in the POST body though) 

Which leads to an interesting question... application/x-www-form-urlencoded is an accepted standard for encoding, but it's really inefficient for text that contains a lot of non-alphanumeric characters.  The W3C spec acknowledges this and suggests multipart/form-data as an alternative, which is even less-suitable, since this just breaks up your data into chunks of form encoded and plain text (or other encodings).  Also, x-www-form-urlencoded is really strange - even though servers seem happy with %20 -> ' ' [space character], the spec actually mandates that all spaces be sent as '+' characters.

So... should we use application/x-www-form-urlencoded?  Should we interpret data like that regardless of the content-type?  Setting the content-type to text/plain seems to be the only option if we want to avoid a preflight.  Seems like the correct thing to do would be to start supporting the OPTIONS request and set the content-type to whatever we want (application/json maybe?).  I'm personally in favor of using a more optimal encoding like text/plain with the content encoded in JSON, but I'm not sure I understand the ramifications entirely as far as character sets and the like go...

(transport implementation detail: if we use JSON to encode the form data, we should make sure all the arguments are strings before calling JSON.stringify to avoid weird results with class instances used as objects as well as maintain consistency with other transports that merely call toString())