Syntaxe du constructeur

new Request(input [, init])

Paramètres du constructeur

• input : peut être un objet USVString contenant l'URL ou un objet Request existant. Notez que la propriété url étant immuable, lorsque vous modifiez une demande et l'URL, vous devez transmettre la nouvelle URL dans ce paramètre.

• init (facultatif) : objet d'options contenant des paramètres personnalisés à appliquer à la demande. Les options valides sont les suivantes :

  • method : méthode de demande, telle que GET ou POST
  • headers : objet Headers

    • body : tout texte à ajouter à la demande.

      Les requêtes utilisant les méthodes HEAD ou GET ne peuvent pas comporter de corps.

    • redirect : mode respecté lors de l'extraction de la demande. La valeur par défaut des demandes générées à partir de l'objet fetchEvent entrant du gestionnaire d'événements est manual. La valeur par défaut des demandes nouvellement construites (en d'autres termes, new Request (url)) est follow. Options valides :

      • follow : si une réponse de redirection est renvoyée à l'extraction, une autre extraction est déclenchée en fonction de l'en-tête Location de la réponse jusqu'à ce qu'un code de non redirection soit renvoyé. Par exemple, await fetch(..) n'a jamais pu renvoyer une redirection 301.
      • manual : les réponses de redirection sont renvoyées d'une extraction.

Propriétés

Toutes les propriétés d'un objet Request entrant (event.request) sont en lecture seule. Pour modifier une demande, vous devez créer un objet Request et transmettre les options à modifier à son constructeur.

• body : simple méthode d'accès get qui expose un ReadableStream du contenu.
• bodyUsed : valeur booléenne qui déclare si le corps a été utilisé dans une réponse.
• cf : objet qui contient les données fournies par nos partenaires chez Cloudflare.
• headers : contient l'objet Headers associé de la demande.
• method : méthode de demande, telle que GET ou POST, associée à la demande.
• redirect : mode de redirection à utiliser ( follow ou manual).
• url : contient l'URL de la demande.

L'objet cf

En plus des propriétés de l'objet Request standard, vous pouvez utiliser un objet request.cf pour contrôler la manière dont les fonctionnalités sont appliquées, ainsi que les autres informations personnalisées fournies par Cloudflare. Par exemple :

  if (request.cf.asn == 64512) {
    return new Response('Block the ASN 64512 response')
  }

Si vous utilisez Workers Playground pour écrire et tester vos scripts, le contenu request.cf n'est pas disponible en mode aperçu. Vous devez être en production pour exécuter ce contenu.

Ces propriétés contiennent des informations spéciales d'une demande entrante pour vous aider avec la logique de votre application. Tous les plans ont accès à :

• asn : ASN de la demande entrante (par exemple, 395747).
• colo : code aéroport de trois lettres du centre de données auquel la demande accède (par exemple, "DFW").
• weight: : pondération demandée par le navigateur pour la hiérarchisation HTTP/2.
• exclusive: : indicateur exclusif HTTP/2 demandé par le navigateur (1 pour les navigateurs Chromium, 0 pour les autres).
• group: : ID flux HTTP/2 du groupe de demandes (non nul uniquement pour Firefox).
• group-weight : pondération HTTP/2 du groupe de demandes (non nul uniquement pour Firefox).
• tlsCipher : chiffrement de la connexion à CIS (par exemple, "AEAD-AES128-GCM-SHA256").
• country : code pays à deux lettres de la demande entrante. La même valeur est fournie dans l'en-tête CF-IPCountry (par exemple, "US").
• tlsClientAuth : défini uniquement si activé pour mTLS. L'objet possède les propriétés suivantes : certIssuerDNLegacy, certIssuerDN, certIssuerDNRFC2253, certSubjectDNLegacy, certVerified, certNotAfter, certSubjectDN, certFingerprintSHA1, certNotBefore, certSerial, certPresented, certSubjectDNRFC2253
• tlsVersion : version TLS de la connexion à CIS (par exemple, TLSv1.3).

Les plans Standard et Enterprise ont accès à :

• requestPriority : informations de hiérarchisation demandées par le navigateur dans l'objet de demande (par exemple, “weight=192;exclusive=0;group=3;group-weight=127”).
• city : ville de la demande entrante (par exemple, "Austin").
• continent : continent de la demande entrante (par exemple, "NA").
• httpProtocol : protocole HTTP (par exemple, "HTTP/2").
• latitude : Latitude de la demande entrante (par exemple, "30.27130").
• longitude : Longitude de la demande entrante (par exemple, "-97.74260").
• postalCode : Code postal de la demande entrante (par exemple, "78701").
• region: Si elle est connue, la désignation ISO 3166-2 de la région de premier niveau associée à l'adresse IP de la requête entrante. S'il n'est pas connu, chaîne vide (par exemple, "Texas").
• regionCode: Si elle est connue, la norme ISO 3166-2 correspondant à la région de premier niveau associée à l'adresse IP de la requête entrante. S'il n'est pas connu, chaîne vide (par exemple, "TX").
• timezone : fuseau horaire de la demande entrante (par exemple, "America/Chicago").

Tous les plans peuvent définir ces fonctions sur les demandes sortantes.

• cacheEverything : cette option force CIS à mettre en cache la réponse de cette demande, quels que soient les en-têtes visibles sur la réponse. Cela revient à définir la règle de page Niveau de mise en cache sur Tout mettre en cache (par exemple, true).

• scrapeShield : active ou désactive ScrapeShield (par exemple, false).

• polish : définit le mode de perfectionnement de Cloudflare. Les valeurs possibles sont "lossy", "lossless" et "off" (par exemple, lossless).

• minify : optimisation du site Web pour activer/désactiver la fonction Autominify de Cloudflare pour divers types de fichier. La valeur est un objet contenant des zones booléennes pour javascript, css et html (par exemple, { javascript: true, css: true, html: false }).

• mirage : optimisation des images pour activer/désactiver la fonction mirage de Cloudflare. Si vous spécifiez cette option, sa valeur doit toujours être false (par exemple, false).

• cacheTtl : cette option force CIS à mettre en cache la réponse de cette demande, quels que soient les en-têtes visibles sur la réponse. Cela revient à définir deux règles de page : la durée de vie du cache en périphérie (Edge Cache TTL) et le niveau de mise en cache (pour tout mettre en cache, par exemple 300).

• resolveOverride : redirige la demande vers un autre serveur d'origine. Vous pouvez utiliser cette option pour implémenter l'équilibrage de charge sur plusieurs origines (par exemple, us-east.example.com).

  Pour des raisons de sécurité, le nom d'hôte défini dans resolveOverride doit être transmis par proxy à la même zone CIS de la demande entrante. Sinon, le paramètre est ignoré. Les hôtes CNAME étant autorisés, pour résoudre un hôte CNAME en un hôte sous un autre domaine ou un domaine DNS uniquement, déclarez un enregistrement CNAME dans le mappage DNS au nom d'hôte de votre propre zone, définissez le proxy sur CIS, puis définissez l'option resolveOverride de sorte qu'elle pointe vers cet enregistrement CNAME.

Entreprise uniquement

• cacheKey : une clé de cache d'une demande détermine si deux demandes sont "identiques" à des fins de mise en cache. Si une demande possède la même clé de cache qu'une demande précédente, nous pouvons servir la même réponse en cache pour les deux demandes (par exemple, 'some-key').

• cacheTtlByStatus : cette option est une version de la fonctionnalité cacheTtl qui choisit un TTL en fonction du code de statut de la réponse. Si la réponse à cette demande possède un code de statut correspondant, CIS la met en cache pour la durée spécifiée et remplace les instructions de mise en cache envoyées par l'origine (par exemple, { "200-299": 86400, 404: 1, "500-599": 0 }).

  CIS respectant toujours les niveaux de cache standard, le comportement de mise en cache des fichiers statiques est donc remplacé par défaut. Si vous souhaitez mettre en cache des ressources non statiques, vous devez définir le niveau de mise en cache sur Tout mettre en cache à l'aide d'une règle de page.

Un script de fonctions Edge est exécuté après les fonctionnalités de sécurité CIS, mais avant tout autre chose. Par conséquent, un script de fonctions Edge ne peut pas affecter le fonctionnement des fonctionnalités de sécurité (puisqu'elles sont déjà finalisées), mais il peut affecter d'autres fonctionnalités, telles que l'optimisation de la taille des images ou la manière dont la réponse est mise en cache en périphérie.

La mise à jour de l'objet cf est similaire à la modification d'une demande. Vous pouvez ajouter l'objet cf à un objet Request en transmettant un objet personnalisé à fetch.

// Disable ScrapeShield for this request.
fetch(event.request, { cf: { scrapeShield: false } })

Les paramètres non valides ou de nom incorrect dans l'objet cf sont ignorés automatiquement. Prenez soin de vérifier que vous obtenez bien le comportement souhaité.