-
Notifications
You must be signed in to change notification settings - Fork 62
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
66 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| # GraphQL-over-HTTP WG - 25th January 2024 | ||
|
|
||
| **Watch the replay**: | ||
| https://www.youtube.com/watch?v=nHSixplvCc0&list=PLP1igyLx8foEz9127xc0SsabIrbTMt9g5 | ||
|
|
||
| Agenda: | ||
| https://github.com/graphql/graphql-over-http/blob/main/working-group/agendas/2025/01-Jan/30-graphql-over-http-wg-january-2025.md | ||
|
|
||
| Participants: | ||
|
|
||
| - @shane32 | ||
| - @martinbonnin | ||
| - @benjie | ||
| - @enisdenjo | ||
|
|
||
| ## Watershed | ||
|
|
||
| - [https://github.com/graphql/graphql-over-http/pull/322](https://github.com/graphql/graphql-over-http/pull/322) | ||
| - Aim of the spec: | ||
| - Benjie: describe the status quo | ||
| - Benjie: increase compatibility by describing what’s used right now | ||
| - Benjie: this was expected to be released pretty quickly. The watershed dates | ||
| ~2 years ago. | ||
| - Security and other discussions have delayed the 1.0 release | ||
| - Follow up features: | ||
| - Batched variables | ||
| - Trusted documents | ||
| - Etc… | ||
| - Denis: the “must” are implemented. The “should” are not always | ||
| - It’s not released yet | ||
| - Benjie: serving over HTTP is relatively straightforward. | ||
| - People were just using the “serving over HTTP” page. Requiring the new content | ||
| type would break those. | ||
| - Shane: technically, a server that does not support the new content-type | ||
| wouldn’t be compliant because they would not auto switch. | ||
| - There’s a difference between server and clients. We could require clients to | ||
| send both content-types and relieve some of the pain for server. | ||
| - Shane: HTTP spec mandates the order of the Accept header. Or is it? | ||
| - Benjie: We could remove the watershed and release as-is | ||
| - Benjie: partial HTTP status code is probably something we want to add before | ||
| releasing | ||
| - Denis: 200 is recommended only if there are no “errors” | ||
| - Benjie: We could make an update with a “should” but it’d be better for | ||
| compatibility if we could make it a “must”. | ||
| - Benjie: we should consider making 200 a “MUST” if data is present and there is | ||
| no error. | ||
|
|
||
| ## Spec status | ||
|
|
||
| - What about clients sending no “accept” headers? | ||
| - If the client doesn’t send an “accept” header, the client can do whatever it | ||
| wants | ||
| - We could mandate the “accept” header for any graphql client. | ||
| - Is this something we include in the testing suite? | ||
| - Not really, testing clients is a lot of work. | ||
| - Does it matter if a curl client isn’t a compliant client? | ||
| - Maybe not as long as the server would return something. The script would still | ||
| work. | ||
| - If we want to change the aim of the spec, we can! Filing an issue is the way | ||
| to go. | ||
| - Benjie: question for the GraphQL foundation board: how many requests do not | ||
| have an “accept” header? | ||
| - Martin: would be also useful to know what percentage of servers support the | ||
| new media type | ||
| - Benjie: the only thing holding the spec back is security. | ||
| - Issue 280 |