[apollo-server-koa] sending wrong content-type returns 500 without description

Expected Behavior: Requesting the graphql endpoint using POST and a content-type header that is not application/json or maybe application/graphql should result in a 400 Bad Request or 415 Unsupported Media Type response from the server with a meaningful response in the body.

Current Behavior: Requesting the POST endpoint with e.g. content-type header text/plain results in a 500 Internal Server Error response with the following body: {}. Imho this is semantically incorrect (the client did the mistake, not the sever) and not helpful (no explanation of the error at all).

Details: I looked into this a bit and I cant find where the error is coming from. The request goes into the bodyParser middleware, which resolves with {}. Then the subsequent middleware is not called anymore and I don’t know why…

Steps to reproduce:

Install: npm i koa@2.5.3 apollo-server-koa@2.1.0 supertest@3.3.0

Run:

const Koa = require('koa');
const { ApolloServer } = require('apollo-server-koa');
const supertest = require('supertest');

const RootQuery = 'type RootQuery { ping: String!, pingUserId: String! }';
const SchemaDefinition = 'schema { query: RootQuery }';
const resolvers = {
    RootQuery: {
        ping() {
            return 'pong';
        }
    }
};
const graphqlServerOptions = { typeDefs: [ SchemaDefinition, RootQuery ], resolvers };

const app = new Koa();
const graphqlServer = new ApolloServer(graphqlServerOptions);

graphqlServer.applyMiddleware({
    app,
    path: '/api'
});


async function runExample() {
    const contentType = 'text/plain';
    const server = app.listen();
    const request = supertest(server);
    const response = await request.post('/api')
        .set('Content-Type', contentType)
        .send(JSON.stringify({ query: '{ping}' }));

    console.log(response.statusCode);
    console.log(response.body);

    server.close();
}

runExample();

[glasser]

Fixed on release-3.0 by #5305.

[glasser]

We’re no longer planning to resolve #3184 in AS3. I will look into how reasonable it is to resolve this issue specifically in the context of AS3 vs waiting for a release with #3184.