-
-
Notifications
You must be signed in to change notification settings - Fork 415
Parsing request body mulitple times behaves oddly. #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hey, First and foremost, thanks for reporting this issue, nice catch! Looking at the code in instance (FromJSON a, HasServer sublayout)
=> HasServer (ReqBody a :> sublayout) where
type Server (ReqBody a :> sublayout) =
a -> Server sublayout
route Proxy subserver request respond = do
mrqbody <- decode' <$> lazyRequestBody request
case mrqbody of
Nothing -> respond $ failWith InvalidBody
Just v -> route (Proxy :: Proxy sublayout) (subserver v) request respond We're not trying to be too smart here, so it seems that running
@jkarni @soenkehahn @mf59816 One solution would be to rely on something Julian is working on: canonicalize the API type to 1/ make the routing O(log n) 2/ put the request bodies at the very end of the endpoints they appear in, so that the request body is the last thing we (try to) extract. Any other ideas? |
Pretty serious issue - thanks @mf59816 for reporting! https://github.com/haskell-servant/servant-server/pull/3 has what I think is a fix. I haven't tested it yet though - mf, if you want to add the example you gave here as a test case in the servant-server that'd be very welcome. If not, I'll do it myself soon. |
Add .gitignore file which ignore sandbox files
This test case reproduces servant issue #3.
Consider the routing table:
The first route fails for Put requests, but the second will find that
the request body has already been parsed, and will complain about ""
not being a parseable json representation of
User
.The work-around is simple:
But I'm not sure it is that simple in all cases, or that obvious to
understand the situation once you've stumbled into this trap.
We have some (limited) resources to work on a solution, but we would
like to hear what you think first.
Servant is AWwesome, btw. Thanks for writing it! (:
The text was updated successfully, but these errors were encountered: