From e5d98a96948ed96197a294bbe932d44ee1ee862b Mon Sep 17 00:00:00 2001 From: Benjie Gillam Date: Mon, 3 Aug 2026 10:12:52 +0100 Subject: [PATCH 1/5] Consistency of reference to IETF RFCs --- spec/GraphQLOverHTTP.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/spec/GraphQLOverHTTP.md b/spec/GraphQLOverHTTP.md index 389c0960..ec4b6c45 100644 --- a/spec/GraphQLOverHTTP.md +++ b/spec/GraphQLOverHTTP.md @@ -225,8 +225,8 @@ be part of a well-formed _GraphQL-over-HTTP request_. ## Accept A client MUST indicate the media types that it supports in responses using the -`Accept` HTTP header as specified in -[RFC7231](https://datatracker.ietf.org/doc/html/rfc7231). +`Accept` HTTP header; this header is specified in +[IETF RFC 9110](https://httpwg.org/specs/rfc9110.html#field.accept). Note: If a client does not supply the `Accept` header then the server may respond with an error, or with any content type it chooses (including serving a @@ -282,7 +282,7 @@ necessary to conform with the long-established semantics of safe methods within HTTP. Note: If status code `405` is used then the `Allow` header must be included as -per [RFC9110](https://httpwg.org/specs/rfc9110.html#status.405). +required by [IETF RFC 9110](https://httpwg.org/specs/rfc9110.html#status.405). ### Example @@ -312,7 +312,8 @@ _GraphQL-over-HTTP request_ parameters encoded in one of the officially recognized GraphQL media types, or another media type supported by the server. A client MUST indicate the media type of a request body using the `Content-Type` -header as specified in [RFC7231](https://datatracker.ietf.org/doc/html/rfc7231). +header; this header is specified in +[IETF RFC 9110](https://httpwg.org/specs/rfc9110.html#field.content-type). A server MUST support POST requests encoded with the `application/json` media type (as indicated by the `Content-Type` header) encoded with UTF-8. @@ -410,7 +411,7 @@ validating and executing the requested operation if successful, and describes any errors encountered during the request. A server must comply with -[RFC7231](https://datatracker.ietf.org/doc/html/rfc7231). +[IETF RFC 9110](https://httpwg.org/specs/rfc9110.html). ## Body @@ -645,7 +646,7 @@ response; it still indicates successful execution. # Non-normative notes This section of the specification is non-normative, even where the words and -phrases specified in RFC2119 are used. +phrases specified in IETF RFC 2119 are used. ## Partial success @@ -736,9 +737,9 @@ HTTP request size would suggest. ### Other resources For more detailed security considerations, please refer to -[RFC 7231](https://tools.ietf.org/html/rfc7231), -[RFC 6454](https://tools.ietf.org/html/rfc6454), other relevant RFCs, and other -resources such as [OWASP](https://owasp.org). +[IETF RFC 9110](https://httpwg.org/specs/rfc9110.html), +[IETF RFC 6454](https://tools.ietf.org/html/rfc6454), other relevant RFCs, and +other resources such as [OWASP](https://owasp.org). ## Future compatibility From 962d97f509dddc77fbda9ae349c5bf6020c74825 Mon Sep 17 00:00:00 2001 From: Benjie Gillam Date: Mon, 3 Aug 2026 10:21:11 +0100 Subject: [PATCH 2/5] Missed one --- spec/GraphQLOverHTTP.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec/GraphQLOverHTTP.md b/spec/GraphQLOverHTTP.md index ec4b6c45..b5a63e14 100644 --- a/spec/GraphQLOverHTTP.md +++ b/spec/GraphQLOverHTTP.md @@ -434,9 +434,9 @@ header and attempt to encode the response in the highest priority media type listed that is supported by the server. In alignment with the -[HTTP 1.1 Accept](https://tools.ietf.org/html/rfc7231#section-5.3.2) -specification, when a client does not include at least one supported media type -in the `Accept` HTTP header, the server MUST either: +[IETF RFC 9110 specification of `Accept`](https://httpwg.org/specs/rfc9110.html#field.accept), +when a client does not include at least one supported media type in the `Accept` +HTTP header, the server MUST either: 1. Respond with a `406 Not Acceptable` status code and stop processing the request; OR From a189f10fb83e3ccb9aae65613c17ba49a50bc2bc Mon Sep 17 00:00:00 2001 From: Benjie Gillam Date: Mon, 3 Aug 2026 10:38:11 +0100 Subject: [PATCH 3/5] Fix wording around Accept --- spec/GraphQLOverHTTP.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/GraphQLOverHTTP.md b/spec/GraphQLOverHTTP.md index b5a63e14..4e0f4df8 100644 --- a/spec/GraphQLOverHTTP.md +++ b/spec/GraphQLOverHTTP.md @@ -435,8 +435,8 @@ listed that is supported by the server. In alignment with the [IETF RFC 9110 specification of `Accept`](https://httpwg.org/specs/rfc9110.html#field.accept), -when a client does not include at least one supported media type in the `Accept` -HTTP header, the server MUST either: +when the request includes an `Accept` header and no supported media type is +acceptable according to that header, the server MUST either: 1. Respond with a `406 Not Acceptable` status code and stop processing the request; OR From 9d610198a22ccc75b35f2cb159a3288f63921c1c Mon Sep 17 00:00:00 2001 From: Benjie Gillam Date: Mon, 3 Aug 2026 17:23:49 +0100 Subject: [PATCH 4/5] Add link --- spec/GraphQLOverHTTP.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/spec/GraphQLOverHTTP.md b/spec/GraphQLOverHTTP.md index 4e0f4df8..05afdf2d 100644 --- a/spec/GraphQLOverHTTP.md +++ b/spec/GraphQLOverHTTP.md @@ -646,7 +646,8 @@ response; it still indicates successful execution. # Non-normative notes This section of the specification is non-normative, even where the words and -phrases specified in IETF RFC 2119 are used. +phrases specified in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) are +used. ## Partial success From 9bffebb52ef934ffc7027e5868721b8db0164177 Mon Sep 17 00:00:00 2001 From: Benjie Gillam Date: Mon, 3 Aug 2026 17:24:14 +0100 Subject: [PATCH 5/5] Change Accept to Content Negotiation --- spec/GraphQLOverHTTP.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/GraphQLOverHTTP.md b/spec/GraphQLOverHTTP.md index 05afdf2d..11e77e82 100644 --- a/spec/GraphQLOverHTTP.md +++ b/spec/GraphQLOverHTTP.md @@ -434,7 +434,7 @@ header and attempt to encode the response in the highest priority media type listed that is supported by the server. In alignment with the -[IETF RFC 9110 specification of `Accept`](https://httpwg.org/specs/rfc9110.html#field.accept), +[IETF RFC 9110 Content Negotiation](https://httpwg.org/specs/rfc9110.html#content.negotiation), when the request includes an `Accept` header and no supported media type is acceptable according to that header, the server MUST either: