POST request helper improvements
Jonplussed opened this issue · comments
It seems the post function helper could be improved. Currently, it's an alias to request methodPost with empty headers— meaning that the parameters POST body not is parsed by WAI.
Since the usual use-case for a POST is with parameters in the body, I think a better helper might have a type like post :: ByteString -> Query -> WaiSession SResponse, where the application/x-www-form-urlencoded content-type header is already provided. A separate helper such as post' could have a type like post :: ByteString -> SimpleQuery -> WaiSession SResponse. Deviations from the usual POST usage would still be free to use the generic request function.
Happy to send a pull request if you believe this is worthwhile!
Hey, see also #19. We should do something here. Introducing functions with the types you mentioned sounds like a good to me. I would still tend to keep the generic post and have either separate functions or a separate module for form/html app testing.
Yes, please open a PR, but be ready for some bikeshedding.
#23 created, which adds versions of post, put, and patch that take a key-value list of params to encode. Bike-shed away!
Oh, bummer! renderSimpleQuery does not do the right thing for post bodies. Spaces should be encoded as + and newlines as %0D%0A (see http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1)...
Right now I'm actually inclined to find out what scotty uses to decode form data.
I just took a look at the parseQuery source and it doesn't use a true parser (making me suspect it's rather error-prone). I chased Scotty code back to WAI and found that it too depends on parseSimpleQuery via this function.
If you haven't filed an issue, I'm happy to recreate it and file an issue/pull-request on Network.HTTP.Types.
Hm, I think the issue is with wai-extra. I assume the stuff in http-types does the right think for URLs. But using it for application/x-www-form-urlencoded is not quite right. Even though it mostly does the right thing, it does not revert the newline normalization, say e.g.
foo%0D%0Abar is decode as foo\r\nbar instead of foo\nbar.
So, basically, what I'm saying is that the functions in http-types are correct, they are just used for the wrong purpose.
Regarding the newline issue I opened scotty-web/scotty#127 and yesodweb/wai#305.
Thanks; I'm not familiar enough with the RFCs to know where in the chain the wrong behavior is occurring.
I've removed the postQuery for now. I'm happy to add it, but somebody has to write a correct implementation of application/x-www-form-urlencoded. I think we should also work on tuples of String rather than ByteString (the not standardized but commonly agreed upon way to do this is first encode utf8, then application/x-www-form-urlencoded).
I'm looking into his right now.
@Jonplussed @ryantm FYI, I just pushed hspec-wai-0.6.1 to Hackage. It provides postHtmlForm which can be used to submit urlencoded HTML forms.
@sol Thank you! 👍
@sol Thanks a bunch!