Partager via

Demande préliminaire de fichier

  • Article

L’opération Preflight File Request interroge les règles CORS (Cross-Origin Resource Sharing) pour Azure Files avant d’envoyer la demande.

Un navigateur web ou un autre agent utilisateur envoie une demande préliminaire qui inclut le domaine d’origine, la méthode et les en-têtes pour la demande que l’agent souhaite effectuer. Si CORS est activé pour Azure Files, Azure Files évalue la demande préliminaire par rapport aux règles CORS que le propriétaire du compte a configurées via Définir les propriétés du service de fichiers. Azure Files accepte ou rejette ensuite la demande.

Pour plus d’informations sur CORS et la demande préliminaire, consultez la spécification CORS et laprise en charge de CORS pour stockage Azure.

Disponibilité du protocole

Protocole de partage de fichiers activé Disponible
SMB Oui
NFS Oui

Requête

Vous pouvez spécifier Preflight File Request comme suit. Remplacez <account-name> par le nom de votre compte de stockage. Remplacez par <file-resource> la ressource de partage, de répertoire ou de fichier qui sera la cible de la requête.

Verbe HTTP URI de demande Version HTTP
OPTIONS http://<account-name>.file.core.windows.net/<file-resource>

http://<account-name>.file.core.windows.net/<file-resource>?restype=share

http://<account-name>.file.core.windows.net/<file-resource>?restype=directory		 HTTP/1.1

L’URI doit toujours inclure la barre oblique (/) pour séparer le nom d’hôte des parties chemin d’accès et requête de l’URI. Dans le cas de cette opération, la partie chemin d’accès de l’URI peut être vide ou pointer vers n’importe quelle ressource Azure Files. Si la ressource Azure Files est un partage ou un répertoire, le paramètre de restype requête est requis.

La ressource peut exister ou ne pas exister au moment où la demande préliminaire est effectuée. La demande préliminaire est évaluée au niveau du service par rapport aux règles CORS du service, de sorte que la présence ou l’absence du nom de la ressource n’affecte pas la réussite ou l’échec de l’opération.

Paramètres URI

Aucun.

En-têtes de requête

Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs :

En-tête de requête Description
Origin Obligatoire. Spécifie l’origine à partir de laquelle la demande sera émise. L'origine est comparée aux règles CORS du service afin de déterminer le succès ou l'échec de la demande préliminaire.
Access-Control-Request-Method Obligatoire. Spécifie la méthode (ou le verbe HTTP) pour la requête. La méthode est comparée aux règles CORS du service afin de déterminer le succès ou l'échec de la demande préliminaire.
Access-Control-Request-Headers facultatif. Spécifie les en-têtes de requête qui seront envoyés. S’il n’est pas présent, le service part du principe que la requête n’inclut pas d’en-têtes.
x-ms-allow-trailing-dot: { <Boolean> } facultatif. Version 2022-11-02 et ultérieures. La valeur booléenne spécifie si un point de fin présent dans l’URL de la demande doit être supprimé ou non. Pour plus d’informations, consultez Affectation de noms et référencement de partages, de répertoires, de fichiers et de métadonnées.

Corps de la demande

Aucun.

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie envoie le code d'état 200 (OK).

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

Pour plus d’informations sur les en-têtes de requête préliminaire, consultez la spécification CORS.

En-tête de réponse Description
Access-Control-Allow-Origin Indique l’origine autorisée, qui correspond à l’en-tête d’origine dans la demande si la demande préliminaire réussit.
Access-Control-Allow-Methods Si la demande préliminaire réussit, cet en-tête est défini sur la ou les valeurs spécifiées pour l’en-tête Access-Control-Request-Methodde requête .
Access-Control-Allow-Headers Si la demande préliminaire réussit, cet en-tête est défini sur la ou les valeurs spécifiées pour l’en-tête Access-Control-Request-Headersde requête .
Access-Control-Max-Age Spécifie la durée pendant laquelle l’agent utilisateur est autorisé à mettre en cache la demande préliminaire pour les demandes futures.
Access-Control-Allow-Credentials Indique si la demande peut être effectuée via des informations d’identification. Cet en-tête a toujours la valeur true.

Response body

Aucun.

Autorisation

L’opération Preflight File Request s’exécute toujours de manière anonyme. Il ne nécessite pas d’autorisation et ignore les informations d’identification si elles sont fournies.

Notes

Si vous avez activé l’analytique stockage Azure et que vous journalise les métriques, un appel à l’opération Preflight File Request est enregistré sous la forme AnonymousSuccess. Pour cette raison, si vous affichez des métriques dans le Portail Azure, vous verrez AnonymousSuccess journalisé pour Preflight File Request. Cette métrique n’indique pas que vos données privées ont été compromises, mais seulement que l’opération Preflight File Request a réussi avec un code de status de 200 (OK).

Exemple de requête et de réponse

L’exemple suivant envoie une demande préliminaire pour l’origine www.contoso.com. La méthode de requête est définie sur PUT, et les en-têtes de requête sont définis sur content-type et accept.

OPTIONS http://myaccount.file.core.windows.net/myshare/myfile  
HTTP/1.1  
Accept: */*  
Origin: www.contoso.com  
Access-Control-Request-Method: PUT  
Access-Control-Request-Headers: content-type, accept  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)  
Content-Length: 0

La réponse indique que CORS est activé pour le service et qu’une règle CORS correspond à la demande préliminaire :

HTTP/1.1 200 OK  
Connection: Keep-Alive  
Content-Length: 0  
Content-Type: text/html; charset=UTF-8  
Access-Control-Allow-Origin: *  
Access-Control-Max-Age: 60  
Access-Control-Allow-Methods: PUT  
Access-Control-Allow-Headers: accept,content-type

Remarques

Si CORS est activé pour le service et qu’une règle CORS correspond à la demande de contrôle préliminaire, le service répond à la demande préliminaire avec status code 200 (OK). Cette réponse comprend les en-têtes Access-Control nécessaires. Dans ce cas, la demande est facturée.

Si les règles CORS ne sont pas activées ou si aucune d'elles ne correspond à la demande préliminaire, le service répond avec le code d'état 403 (Interdit). Dans ce cas, la demande n’est pas facturée.

Si la OPTIONS demande est incorrecte, le service répond avec status code 400 (demande incorrecte) et la demande n’est pas facturée. Un exemple de requête incorrecte est une requête qui ne contient pas les en-têtes et Access-Control-Request-Method requisOrigin.

La demande préliminaire est un mécanisme permettant d’interroger la fonctionnalité CORS d’un service de stockage associé à un compte de stockage spécifique. La demande préliminaire n'est pas destinée à une ressource spécifique.