Comments (8)
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 fully support the HTTP specification. I would not think those specifications would need to be reiterated. It should be rather obvious that Accept: */*
should act in the same manner as if Accept
were not supplied, as the GraphQL over HTTP protocol defines the default content type during and after the legacy watershed period, and this matches Accept: */*
. Perhaps the wording could be changed to say 'default content type' rather than 'when the Accept header is not specified', just to be more clear.
from graphql-over-http.
Yes, that's correct. In reality most web-based GraphQL clients will actually send Accept: */*
though, if the Accept header wasn't specified explicitly by the developer. See the fetch spec (13.)
I don't have numbers to back this up, but I would assume that nearly 100% of GraphQL requests in browsers are done through the fetch
API and of those at least 90% aren't specifying an explicit Accept
header.
I think we're in a weird spot, since legacy clients might unknowingly tell the server they accept anything, while they probably don't in reality.
from graphql-over-http.
According to the reference implementation */*
is treated as application/json
for now: https://github.com/graphql/graphql-http/blob/main/src/handler.ts#L689
from graphql-over-http.
It’s the servers choice; but I think defaulting too application/json prior to watershed and application/graphql-response+json after is reasonable. In fact you could go hybrid and use graphql-response on error even now so you can start using the HTTP codes!
from graphql-over-http.
Yes, that would be good @Shane32.
from graphql-over-http.
I actually disagree here. A client that sets no accept header expects the default. A client that says Accept: */*
is explicitly telling the server: use whatever content type is most appropriate, I can handle it.
from graphql-over-http.
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
header is equivalent to Accept: */*
from graphql-over-http.
Though that is indeed what the spec says (which aligns with what I suggest for users who explicitly set Accept: */*
), I think the majority of GraphQL clients that don’t set Accept and won’t easily be updated to add an Accept header will be one-off shell scripts and other such ad-hoc uses which still expect application/json since that’s the current behaviour of most servers, so maintaining that until watershed makes sense to me.
But either way, it’s the server’s choice, I don’t think we need to dictate this.
from graphql-over-http.
Related Issues (20)
- Next meeting: Thurs July 21st 17:00 UTC? HOT 12
- [2022-06-27] Incorporate David's and working group's feedback
- [2022-06-27] Contact Denis to discuss compatibility with websockets and SSE spec
- [2022-06-27] Check spec-md is working correctly and split the spec up into sections
- [2022-06-27] Go through the issues and close those that are not relevant any more
- [2022-06-27] Copy over relevant issue labels from main spec repo HOT 2
- [2022-06-27] Schedule a meeting after the July spec WG
- Spec references RFC7231 which is obsoleted HOT 4
- Response status code as `application/json` content HOT 5
- Clarify the use of HTTP GET and POST request HOT 2
- Status codes for unauthenticated OAuth errors HOT 1
- Optional query discussion HOT 13
- GraphQL request optional parameters HOT 2
- Kitchen sink HTTP requests HOT 3
- Allow non-UTF-8 encodings HOT 2
- What is well-formed response HOT 3
- Status codes 404 and 410 HOT 1
- Should we explicitly support `Content-Type: application/graphql`? HOT 13
- Should the query property really be required? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphql-over-http.