You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This request produces an error message in the "data" field:
"data": {
"message": "No JSON/bad JSON supplied. If you used Swagger, you'll need to use curl on the CLI with the -d option instead for non-GET methods, or GET-method data for GET."
}
If the Content-Type is set to application/json however, it works as expected:
Sorry for the delay, I was traveling! Now that I'm back home I was able to dig into this.
The issue is known behavior, but not desired behavior. The issue I ran into is that the original httpbin's /post endpoint just... reads all post data, regardless of variable. FastAPI, however, requires variables to be named in its function definitions, so when I first built this I was out of luck.
Or so I thought. :-)
With the benefit of several months having elapsed, I took another look at this, since it was brought up, and discovered that FastAPI has a request.body() function that behaves similar to request.json(), which I was already using. So I added in some support for that, wrote some tests, and "regular" form submissions should be parseable now. I will deploy shortly, and when https://httpbin.dmuth.org/version reports 0.0.47, you'll be good to try again.
It appears that, unlike
httpbin
,fastapi-httpbin
consistently interprets a urlencode payload in aPOST
request as JSON.When a
POST
request is sent tohttpbin
, with the following command:curl
automatically sets theContent-Type
header toapplication/x-www-form-urlencoded
, as its default behavior.httpbin
responds with the following:However, if the
Content-Type
is specified asapplication/json
:The response now includes a populated
"json"
field:In contrast, it appears that
fastapi-httpbin
always expects JSON content, even when theContent-Type
is set toapplication/x-www-form-urlencoded
:This request produces an error message in the
"data"
field:If the
Content-Type
is set toapplication/json
however, it works as expected:The response from
fastapi-httpbin
then successfully populates the"data"
field with the submitted form data:I'm uncertain whether the observed behavior with
content-type: application/x-www-form-urlencoded
, which differs fromhttpbin
, is an intended feature.The text was updated successfully, but these errors were encountered: