#816
- Created on2010-12-29 19:35
- Reported by
- Worked hours2.0 hours
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Access to raw POST data for POST/PUT
Access to raw postdata in the HTTP request chain, both stateful and stateless. Useful for e.g. a REST service that accepts large uploads of binary data and wants to implement its own buffering/decryption/....
Another option could be to have the POST data redirected to a file for some calls (depending on a LiftRule) and indicate that in the S Object.
Another option could be to have the POST data redirected to a file for some calls (depending on a LiftRule) and indicate that in the S Object.
Leave a comment
on 2011-01-06 09:17 *
By maarten.koopmans
I have looked at this and I see a few ways to get started, however... it is indeed complicated and subtle.
The easiest way would be to add a rawParamData : Array[Byte] to Req , which is just set to the body of ParamCalcInfo. But with larger bodies this will blow up as it is memory-mapped.
That would imply that ParamCalcInfo's body parameter should move from Box[Array[Byte]] to a holder class that can be either memory or disk based. I can't estimate the impact of that. We'd have to configure that via LiftRules, and then another decision pops up: should the disk/memory holder be global to the site or per ParsePath? I'd say the latter, but the first would certainly work in >>95% of the cases.
So actually it looks as if we have two changes: one to set the type of buffer for POST/PUT data that is not multipart encoded but large anyway - think XHR2 with Blob file types. This will be the most urgent driver. The second change is making this accessible much like FileParamHolder.
The easiest way would be to add a rawParamData : Array[Byte] to Req , which is just set to the body of ParamCalcInfo. But with larger bodies this will blow up as it is memory-mapped.
That would imply that ParamCalcInfo's body parameter should move from Box[Array[Byte]] to a holder class that can be either memory or disk based. I can't estimate the impact of that. We'd have to configure that via LiftRules, and then another decision pops up: should the disk/memory holder be global to the site or per ParsePath? I'd say the latter, but the first would certainly work in >>95% of the cases.
So actually it looks as if we have two changes: one to set the type of buffer for POST/PUT data that is not multipart encoded but large anyway - think XHR2 with Blob file types. This will be the most urgent driver. The second change is making this accessible much like FileParamHolder.