Add notes from 2025-01 WG (#326)

Author: benjie

working-group/notes/2025/2025-01.md

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