HttpStatus Code on GRAPHQL_VALIDATION error about server HOT 6 OPEN

We can look at adding this feature. (Specifically, that the response status code is dependent not only on the response but the selected content type.) It would likely have to be in the next major version since it probably requires a redesign of some of the protected methods of the middleware. I think ultimately we want to determine the response content type earlier in the middleware logic to allow for adjusting behavior throughout the pipeline, for example to support subscriptions over SSE.

from server.

The latest 7.2.0 follows the draft GraphQL over HTTP spec, which returns application/graphql-response+json and returns 400 in the case of a validation error.

If the GraphQL response does not contain the {data} entry then the server MUST reply with a 4xx or 5xx status code as appropriate.

See: https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#applicationgraphql-responsejson

Both the response content type and status code response are configurable.

See the ValidationErrorsReturnBadRequest option and the DefaultResponseContentType properties of the options. For example:

app.UseGraphQL("/graphql", options =>
{
    options.DefaultResponseContentType = MediaTypeHeaderValueMs.Parse("application/json");
    options.ValidationErrorsReturnBadRequest = false;
});

Note that if the HTTP Accept header is provided to the request, the response will attempt to use a matching content type -- but the selection of the response content type does not alter the response status code. So in the default configuration, 400 errors may be returned with the application/json content type if the application/json content type was requested via the Accept header.

from server.

@gao-artur You provided irrelevant parts of the spec. The problem is not about intermediary servers or content type. The problem is the data itself. @Shane32 pointed in the right direction. Since v7 server returns 4xx if data entry is empty, i.e. execution was not started at all, that means some validation error or any other arbitrary server-side error occurred BEFORE actual execution of GraphQL query.

from server.

@sungam3r You may wish to read this section again https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#applicationjson

@gao-artur is correct that 400 is "strongly discouraged" for well-formed GraphQL responses with the "application/json" content type.

This section only applies when the response body is to use the application/json media type.

The server SHOULD use the 200 status code, independent of any GraphQL request error or GraphQL field error raised.

We are catering to the application/graphql-response+json content type and although we vary the response content type based on the Accept header, we do not have code that sets the status code based on which response content type was selected.

from server.

OK, too many combinations to remember.

from server.

Thanks, this explains the observed behavior and provided configuration indeed solves my issue. But I think this should be the default behavior for application/json as the other one is discouraged

from server.