You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, async-graphql reads the content-type header when parsing a GQL query to know if the query is encoded in JSON or CBOR.
However, it doesn't read the content-encoding header, which might indicate that the query was compressed.
Async-graphql should read the content-encoding header and decompress the payload if needed before parsing the query according to the content-type header. I think it would be sufficient for a first implementation of this feature to only handle gzip compression; and this could be guarded behind a crate feature to mirror what was done with CBOR decoding.
Request compression is a niche use case but it can substantially reduce the volume of data sent to the GQL server. This is why I think it could be important to support this.
The text was updated successfully, but these errors were encountered:
Currently, async-graphql reads the
content-type
header when parsing a GQL query to know if the query is encoded in JSON or CBOR.However, it doesn't read the
content-encoding
header, which might indicate that the query was compressed.Async-graphql should read the
content-encoding
header and decompress the payload if needed before parsing the query according to thecontent-type
header. I think it would be sufficient for a first implementation of this feature to only handlegzip
compression; and this could be guarded behind a crate feature to mirror what was done with CBOR decoding.Request compression is a niche use case but it can substantially reduce the volume of data sent to the GQL server. This is why I think it could be important to support this.
The text was updated successfully, but these errors were encountered: