Comment retourner du contenu gzippé avec AWS API Gateway
Nous avons développé une application qui offre des services de repos serveur et prend en charge l'en-tête Accept-Encoding pour renvoyer le contenu compressé via la valeur d'en-tête Content-Encoding:gzip.
Cette application est déployée sur des instances ec2 sur aws et lorsque nous envoyons une demande avec la valeur Accept-Encoding définie, la réponse est correctement construite.
Nous voulons exposer cette API en utilisant la passerelle API, mais cela fonctionne uniquement pour ne pas compresser les demandes. Lorsque nous envoyons une requête demandant du contenu gzippé, l'en-tête Content-Encoding est défini correctement, mais le contenu de la réponse est corrompu.
Devons-nous définir un paramètre ou une configuration spécifique dans les étapes de réponse d'intégration ou de réponse de méthode?
Cordialement.
Depuis le 19 décembre 2017. AWS API Gateway prend en charge le codage.
Une fois l’API créée, accédez à Paramètres et sélectionnez Activer le codage du contenu.
Aussi ici est la publication officielle d’AWS.
Malheureusement, API Gateway ne prend actuellement pas en charge la compression HTTP. Cependant, il est en considération pour le développement futur.
Pour l'instant, vous devrez renvoyer le contenu non compressé de votre point de terminaison (en omettant l'en-tête Accept-Encoding) afin de le remplacer par un proxy via API Gateway.
Si cela fonctionne pour votre cas d'utilisation, vous pouvez également coder en base64 le contenu compressé, le transférer par proxy via API Gateway et le décoder sur le client.
Merci, .__ Ryan
Seule une solution de contournement, mais si vous définissez Accept-Encoding: identity, vous devriez recevoir le résultat correctement (contrairement à la discussion liée que j'ai trouvée, cela fonctionne pour POST et GET).
Je l'ai fait fonctionner en ajoutant Accept-Encoding à AWS API Gateway Integration Request
Étape 1: Accédez à la console AWS API Gateway, cliquez sur Integration Request. 
Étape 2: Ajoutez Accept-Encoding à la section HTTP Headers, valeur 'identity' (besoin de guillemets simples) 
Étape 3: Cliquez sur Actions -> Deploy API
Si vous utilisez AWS CloudFormation, vous pouvez ajouter yamlIntegration: RequestParameters: integration.request.header.Accept-Encoding: "'identity'
Pour autoriser le contenu GZipped à partir du point de terminaison du proxy HTTP, vous pouvez ajouter */* dans "Types de supports binaires", dans la section "Support binaire" de votre API.
Bien que cette question soit un peu ancienne, j'aimerais ajouter une réponse, car c'est la question la plus regardée. En fait, il existe 2 scénarios liés au renvoi du contenu compressé.
Le premier scénario est celui où vous souhaitez que API Gateway comprime le contenu. Comme le suggère la réponse acceptée, vous pouvez activer le codage du contenu sur votre API, puis le déployer.
Le second scénario est que votre noeud final d'intégration a déjà compressé le résultat et que vous souhaitez simplement le contourner via API Gateway. La solution de contournement traditionnelle consistait à le configurer en tant que type de support binaire. Cependant, cela pourrait être problématique car il commencera à traiter toutes les réponses avec le type de média comme un binaire. De plus, si vous devez gérer plusieurs types de média, votre seul choix serait de le définir comme "*". Si vous utilisez une intégration non proxy, vous perdrez une chance de transformer le résultat.
Pour résoudre le deuxième problème, API Gateway suppose maintenant implicitement que le résultat de la réponse est binaire lorsqu'une intégration proxy est utilisée ET que le contenu est codé (la réponse contient Content-Encoding avec une valeur autre que 'identity'). Vous n’avez plus besoin de configurer les types de supports binaires lorsque ces conditions sont remplies . Toutefois, si vous renvoyez le support binaire réel (par exemple, image, vidéo), vous devez tout de même les configurer en tant que type de support binaire ( s).
Vous pourriez vous demander ce qui se passe lorsque vous avez les deux scénarios. La réponse courte est que API Gateway ne sera pas compressé à nouveau lorsque la réponse contient déjà un en-tête Content-Encoding.
Espérons que cela aide.