FAQ sur l'opération Fetch d'ER - - Centre de documentation Alibaba Cloud

Questions fréquentes concernant l'API Fetch dans EdgeRoutine (ER), notamment la décompression, les limites des sous-requêtes, la validation des URL et les pools de connexions.

L'opération Fetch prend-elle en charge la décompression ?

Par défaut, Fetch décompresse automatiquement les réponses. Les méthodes de décompression suivantes sont disponibles :

decompress : méthode par défaut. Lit l'en-tête content-encoding de la réponse et utilise l'algorithme de décompression spécifié par la valeur la plus à droite autre que Identity. Par exemple, dans content-encoding: gzip, identity, l'algorithme de décompression est gzip. Si cette valeur est supprimée de l'en-tête de réponse, les scénarios suivants se produisent :
- content-encoding: identity, gzip est l'en-tête de réponse d'origine. Après suppression de gzip, l'en-tête devient content-encoding: identity.
- content-encoding: gzip est l'en-tête de réponse d'origine. Après suppression de gzip, seul content-encoding reste.
Remarque
Une fois l'algorithme supprimé de l'en-tête de réponse, les données deviennent lisibles, comme lorsque le serveur d'origine renvoie des données non compressées. ER ne prend en charge que Gzip et génère une exception pour les algorithmes non reconnus. La prise en charge de Brotli pourrait être ajoutée dans les versions ultérieures.
fallbackIdentity : similaire à decompress, mais ne génère pas d'exception en cas d'échec de la décompression. ER traite plutôt la valeur d'algorithme non reconnue comme Identity et transmet les données sans décompression. Dans ce cas, les données peuvent rester illisibles si elles sont toujours compressées.
manual : ne décompresse pas les données.

Pour définir manuellement une politique de décompression, utilisez l'une des méthodes suivantes :

fetch(url, {decompress: "manual"})
fetch(url, {decompress: "fallbackIdentity"})

Quel est le nombre maximal de sous-requêtes prises en charge par Fetch ?

Fetch prend en charge un maximum de 32 sous-requêtes. Cette limite s'applique à tous les contextes, y compris les requêtes capturées sur les points de présence (POP), les redirections 3xx et les appels à l'API Cache. Pour demander une augmentation du quota, soumettez un ticket.

ER peut-il identifier les URL invalides ?

ER ne valide pas les URL. Si une URL contient des caractères invalides, ER renvoie une erreur d'encodage. Assurez-vous que vos URL sont correctement formatées.

Quel est le nombre maximal de connexions prises en charge par un pool de connexions ?

ER met à disposition un pool de connexions pour Fetch afin d'éviter de consommer toutes les connexions avec des handshakes TCP ou SSL. Par défaut, le pool prend en charge jusqu'à 128 connexions. Lorsque cette limite est atteinte, le pool cesse de mettre en cache de nouvelles connexions. Vous pouvez demander une augmentation de ce quota.

Les pools de connexions sont définis par utilisateur et non par requête. Si aucune connexion existante n'est disponible, ER tente d'en créer une nouvelle. ER met en cache une connexion uniquement après avoir récupéré l'intégralité du corps de la réponse.

Le code suivant montre comment garantir la consommation de l'intégralité du corps de la réponse :

async function fetchAndIgnore(url, options) {
  let response = await fetch(url, options);
  // This method forces ER to ignore the response body and ensures that the entire response body is retrieved. 
  await response.ignore();
}