Closed justinvirtualitics closed 1 year ago
A possible fix on the C#/BestHTTP side:
request.FormUsage = BestHTTP.Forms.HTTPFormUsage.UrlEncoded;
It seems that the 256 byte threshold was triggering the default "Automatic" Form Usage setting, which apparently switched it to Multipart instead of UrlEncoded as the server was expecting.
Hi,
I don't think there is any kind of limit on the falcon side regarding the size of the form body.
Can you confirm in the on_post
that the content type is x-www-form-urlencoded
in all cases, even when params
is empty?
Maybe you can switch to multipart in all cases and use the falcon api to handle that: https://falcon.readthedocs.io/en/stable/api/multipart.html
Thanks for the response @CaselIT .
Upon closer investigation, the content type on the falcon side was appearing as changed (to multipart) in that case, I just hadn't noticed it before. So overall it does appear that the issue was on the C#/BestHTTP side specific to my usage, and not a problem with Falcon.
Switching the api to multipart in all cases on the Falcon side is something I may try later, but for now, I have this working as intended.
Thanks again, closing this issue now.
Great, thanks for reporting back
Just adding to @CaselIT's answer, as of Falcon 3+, it is recommended to use req.media
to handle even URL-encoded forms, i.e. form = req.params
becomes form = req.get_media()
(auto_parse_form_urlencoded
is now deprecated).
Setup a simple API, as follows with Falcon 3.1.1:
Call the API from a C# app using BestHTTP/2.
The above works perfectly as long as the strings aren't too large. A simple test case:
I have not found any information about a limit the 100s of bytes for a given field in a POST request like this, and I have reason to believe that this issue is on the Falcon side. I have been able to extract the values (not keys) from req.media and confirmed that the data in question has arrived at the server, but fails to be read through the request params method wrapper.
Any help would be greatly appreciated.