Skip to content
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

Inconsistent Behavior Between fastapi-httpbin and httpbin in Handling urlencode Payload in POST Request #10

Open
lmanc opened this issue Jul 4, 2023 · 1 comment
Assignees

Comments

@lmanc
Copy link

lmanc commented Jul 4, 2023

It appears that, unlike httpbin, fastapi-httpbin consistently interprets a urlencode payload in a POST request as JSON.

When a POST request is sent to httpbin, with the following command:

$ curl -v -d "birthyear=1905&press=%20OK%20" http://www.httpbin.org/post

curl automatically sets the Content-Type header to application/x-www-form-urlencoded, as its default behavior. httpbin responds with the following:

"form": {
    "birthyear": "1905",
    "press": " OK "
},
"json": null

However, if the Content-Type is specified as application/json:

$ curl -v -H "content-type: application/json" -d '{"birthyear": 1905, "press": " OK "}' http://www.httpbin.org/post

The response now includes a populated "json" field:

"json": {
    "birthyear": 1905,
    "press": " OK "
},

In contrast, it appears that fastapi-httpbin always expects JSON content, even when the Content-Type is set to application/x-www-form-urlencoded:

$ curl -v -d "birthyear=1905&press=%20OK%20" https://httpbin.dmuth.org/post

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:

$ curl -v -H "content-type: application/json" -d '{"birthyear": 1905, "press": " OK "}' https://httpbin.dmuth.org/post

The response from fastapi-httpbin then successfully populates the "data" field with the submitted form data:

"data": {
    "birthyear": 1905,
    "press": " OK "
}

I'm uncertain whether the observed behavior with content-type: application/x-www-form-urlencoded, which differs from httpbin, is an intended feature.

@dmuth dmuth self-assigned this Jul 22, 2023
@dmuth
Copy link
Owner

dmuth commented Jul 22, 2023

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.

Thanks,

-- Doug

dmuth added a commit that referenced this issue Jul 22, 2023
dmuth added a commit that referenced this issue Jul 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants