Shane Krueger

Note that 201/202 also are as "safe" of a selection as 203, perhaps moreso. But again, the meaning doesn't carry over to GraphQL's intended use at all.

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...

@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...

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...

Done for v8. By default it will follow GraphQL over HTTP spec and return 200 for `application/json` responses when there are validation errors.

e.g.: `ApplyDirective` vs `WithComplexityImpact`

The HTTP protocol has a number of semantics for the `Accept` header, such as q-factor weighting, which are not covered by the GraphQL over HTTP protocol. A compliant server should...

The HTTP RFC 2616 states: > If no Accept header field is present, then it is assumed that the client accepts all media types. In other words, a missing `Accept`...

I feel that it will hamper further extensions to the protocol if option 2 is selected.

Well, we are basically stating that CLIENT implementations that are compatible with this version of the spec MUST not use other root props, and SERVER implementations MUST ignore additional props,...