Apollo-server: Have better error message when content type is incorrect or query provided in the wrong place

[Shahor]

Description

When you try to call a graphql route with the incorrect Content-Type the server replies with the follow :

{"errors":[{"message":"Must provide document"}]}

Intended outcome

The error message is misleading and makes it hard to debug => Have an explicit error message

[helfer]

@Shahor please be a bit more specific about what content-type and what request you're sending.

Or if you've already looked at the code and established that this will happen with any incorrect content type, a PR would be much appreciated! 🙂

[batjko]

I'm getting this with a basic graphql-server-express, which works fine via GraphiQL, but not via curl, e.g.:
curl -XPOST -H "Content-Type:application/graphql" -d '{ tenants { displayName } }' http://localhost:3002/graphql

[Shahor]

@batjko Content-Type must be application/json

I'm sorry, I would love to work on this but I can't find time right now.

[urbanvikingr]

@batjko

Have you tried something like:

curl -H "Content-Type:application/json" -XPOST http://localhost:3000/graphql -d '{ "query": "{testString}" }'

This works for the apollo-tutorial-kit sample.

[abernix]

Thanks for opening this concern originally. I'll close this issue as it hasn't received a lot of traction since it was first opened.

For anyone arriving at this issue, a suggested Content-type is application/json, but it may vary depending on the server implementation. For example, an upload might use multipart/form-data, rather than application/json.

The above error message is no longer shown — which was holdover from directly relying on graphql-js to throw in these circumstances — instead, when sending a request that is missing a query, the error message will be Must provide query string..

When the body is missing on a POST request, Apollo Server will report: POST body missing. Did you forget use body-parser middleware?. We've also changed the Content-type rules to behave a bit differently since when this was first reported, so it's not clear how common this is. A change in error messages is likely a _major_ breaking change, so I'd like to make sure we have something ubiquitous that would work across all HTTP frameworks and transports if we're going to change these, but I'm sure we would certainly consider a more complete proposal for a major version, if someone still feels strongly about this and wanted to put one together.