Skip to content

Commit cacd928

Browse files
martinbonninShane32benjie
authored
Make "processing a response" non-normative and add a note for clients (#304)
* Clarify server vs intermediary service * Update spec/GraphQLOverHTTP.md Co-authored-by: Shane Krueger <shane@acdmail.com> * Feedbacks: - split the note in 2 - be explicit about response media type * format * Update spec/GraphQLOverHTTP.md Co-authored-by: Shane Krueger <shane@acdmail.com> * Mention intermediary server and 200 (and not 2xx) * spelling * Backtrack, just add the link to the initial note * Update spec/GraphQLOverHTTP.md Co-authored-by: Shane Krueger <shane@acdmail.com> * move processing a response to non-normative notes * forgot on application/ * restore paragraph * reintroduce the MUST NOT compliance requirement * Apply editorial from code review * Format --------- Co-authored-by: Shane Krueger <shane@acdmail.com> Co-authored-by: Benjie Gillam <benjie@jemjie.com>
1 parent c38eb33 commit cacd928

File tree

1 file changed

+32
-13
lines changed

1 file changed

+32
-13
lines changed

spec/GraphQLOverHTTP.md

Lines changed: 32 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -531,12 +531,16 @@ The server SHOULD use the `200` status code for every response to a well-formed
531531
_GraphQL-over-HTTP request_, independent of any _GraphQL request error_ or
532532
_GraphQL field error_ raised.
533533

534+
If the response uses a non-`200` status code then the client MUST NOT rely on
535+
the body to be a well-formed _GraphQL response_.
536+
534537
Note: A status code in the `4xx` or `5xx` ranges or status code `203` (and maybe
535-
others) could originate from intermediary servers; since the client cannot
536-
determine if an `application/json` response with arbitrary status code is a
537-
well-formed _GraphQL response_ (because it cannot trust the source) the server
538-
must use `200` status code to guarantee to the client that the response has not
539-
been generated or modified by an intermediary.
538+
others) could originate from an intermediary; since the client cannot determine
539+
if an `application/json` response with arbitrary status code is a well-formed
540+
_GraphQL response_ (because it cannot trust the source) the server must use
541+
`200` status code to guarantee to the client that the response has not been
542+
generated or modified by an intermediary. See
543+
[processing a response](#sec-Processing-a-response) for more details.
540544

541545
If the _GraphQL response_ contains a non-null {data} entry then the server MUST
542546
use the `200` status code.
@@ -680,6 +684,12 @@ pass validation, then the server SHOULD reply with `400` status code.
680684
If the client is not permitted to issue the GraphQL request then the server
681685
SHOULD reply with `403`, `401` or similar appropriate status code.
682686

687+
Note: When the response media type is `application/graphql-response+json`,
688+
clients can rely on the response being a well-formed _GraphQL response_
689+
regardless of the status code. Intermediary servers may use the status code to
690+
determine the status of the _GraphQL response_ without needing to process the
691+
response body.
692+
683693
#### Examples
684694

685695
The following examples provide guidance on how to deal with specific error cases
@@ -747,19 +757,28 @@ Note: The GraphQL specification
747757
and refers to the situation wherein a _GraphQL field error_ occurs as a partial
748758
response; it still indicates successful execution.
749759

750-
## Processing the response
751-
752-
If the response uses a non-`200` status code and the media type of the response
753-
payload is `application/json` then the client MUST NOT rely on the body to be a
754-
well-formed _GraphQL response_ since the source of the response may not be the
755-
server but instead some intermediary such as API gateways, proxies, firewalls,
756-
etc.
757-
758760
# Non-normative notes
759761

760762
This section of the specification is non-normative, even where the words and
761763
phrases specified in RFC2119 are used.
762764

765+
## Processing a response
766+
767+
In some cases, the response received by a client may not originate from a
768+
GraphQL service, but instead from an intermediary—such as an API gateway, proxy,
769+
firewall or other middleware—that does not implement this specification. Such an
770+
intermediary might produce the response to indicate an error, returning a
771+
response with `4xx` or `5xx` status code and potentially using the standard
772+
`application/json` media type to encode the reason for the error. Such a
773+
response is unlikely to be a valid GraphQL response.
774+
775+
For this reason, a client application can rely on the response being a
776+
well-formed _GraphQL response_ only if at least one of the following conditions
777+
is met:
778+
779+
- the response media type is `application/graphql-response+json`, or
780+
- the status code is `200`.
781+
763782
## Security
764783

765784
This specification focuses solely on the intersection of GraphQL and HTTP.

0 commit comments

Comments
 (0)