[Enhancement] Improve clarity of Bind invalid Content-Type message

[shawn-hurley]

Is there an existing issue for this?

• I have searched the existing issues

Konveyor version

v0.3.0

Priority

Minor

Current Behavior

When calling the API from a client without setting the Content-Type header the application will error with a "Bind: MIME not supported" error, and the response is empty message 400 to the user.

Expected Behavior

I thought that we could do a couple of things, but some extra info to the user would be helpful or what not. @mansam said he thought y'all wanted it to fall back to application/json if it doesn't exist though.

How Reproducible

Always (Default)

Steps To Reproduce

No response

Environment

- OS:

Anything else?

No response

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

[mansam]

I don't seem to be able to reproduce this by using curl to POST to the /applications endpoint without explicitly setting a Content-Type header, or when setting an empty Content-Type. I have to explicitly set an invalid Content-Type to get the error message.

curl -XPOST http://localhost:8080/applications -d '{"name":"testapp"}'
# works

curl -XPOST -H"Content-Type:" http://localhost:8080/applications -d '{"name":"testapp"}'
# works

curl -XPOST -H"Content-Type: " http://localhost:8080/applications -d '{"name":"testapp"}'
# works

curl -XPOST -H"Content-Type: xyz" http://localhost:8080/applications -d '{"name":"testapp"}'
# mime type error, as expected

[shawn-hurley]

Very interesting, I wonder if the javascript Fetch is setting something by default, I think the question would be should we give a reason from the API for the 400?

[shawn-hurley]

After searching, it looks like if empty content in fetch, the spec says it sends text/html by default.

I think that if I was an end user of the API, and I didn't have access to the pod logs, I would be pretty confused about what is going wrong. Unless it does exist already and I didn't see it in my testing for whatever reason. if that is the case let's just close this issue?

[mansam]

The API does return a reason in the message body ({"error":"Bind: MIME not supported."}), but we could revise that to something like {"error":"Bind: Content-Type not supported: text/html"} (where text/html is a placeholder for whatever the offending type is) to help make it more clear what the user might be doing wrong. What do you think?

[shawn-hurley]

+1, now I have to figure out why the body was not printed in my code :)

[jortel]

@shawn-hurley Can this issue be closed?

[mansam]

@jortel I repurposed it into an enhancement issue to improve the clarity of the error message.