A több eredetű erőforrás-megosztás (CORS) támogatása az Azure Storage-banCross-Origin Resource Sharing (CORS) support for Azure Storage

Az 2013-08-15-es verziótól kezdve az Azure Storage-szolgáltatások támogatják a blob-, tábla-és üzenetsor-szolgáltatásokhoz tartozó, a CORS-alapú erőforrás-megosztást.Beginning with version 2013-08-15, the Azure storage services support Cross-Origin Resource Sharing (CORS) for the Blob, Table, and Queue services. A file Service a 2015-02-21-es verziótól kezdve támogatja a CORS.The File service supports CORS beginning with version 2015-02-21.

A CORS egy olyan HTTP-szolgáltatás, amely lehetővé teszi, hogy egy adott tartományban futó webalkalmazás hozzáférhessen egy másik tartomány erőforrásaihoz.CORS is an HTTP feature that enables a web application running under one domain to access resources in another domain. A böngészők olyan biztonsági korlátozást valósítanak meg, amely azonos eredetű házirendet eredményez, amely megakadályozza, hogy egy weblap más tartományba tartozó API-kat hívjon fel. A CORS lehetővé teszi, hogy egy tartomány (a forrás tartomány) egy másik tartományban lévő API-kat hívjon fel.Web browsers implement a security restriction known as same-origin policy that prevents a web page from calling APIs in a different domain; CORS provides a secure way to allow one domain (the origin domain) to call APIs in another domain. A CORS kapcsolatos részletekért tekintse meg a CORS specifikációját .See the CORS specification for details on CORS.

Az egyes Azure Storage-szolgáltatások CORS-szabályait külön-külön is megadhatja a blob szolgáltatás tulajdonságainakmeghívásával, a Fájlszolgáltatások tulajdonságainakbeállítása, a várólista-szolgáltatás tulajdonságainakbeállítása és a Table Service tulajdonságainak beállításabeállítással.You can set CORS rules individually for each of the Azure Storage services, by calling Set Blob Service Properties, Set File Service Properties, Set Queue Service Properties, and Set Table Service Properties. Miután beállította a CORS-szabályokat a szolgáltatáshoz, a rendszer kiértékeli, hogy a szolgáltatás egy másik tartományból érkező, megfelelően engedélyezett kérelmet adott-e meg, és meghatározza, hogy a megadott szabályok szerint engedélyezett-e.Once you set the CORS rules for the service, then a properly authorized request made against the service from a different domain will be evaluated to determine whether it is allowed according to the rules you have specified.

Fontos

A CORS nem engedélyezési mechanizmus.CORS is not an authorization mechanism. Ha a CORS engedélyezve van, akkor a tárolási erőforrásra irányuló kéréseket érvényes engedélyezési fejléctel kell elvégeznie, vagy egy nyilvános erőforráson kell elvégezni.Any request made against a storage resource when CORS is enabled must either have a valid authorization header, or must be made against a public resource.

A CORS minden Storage-fióktípus esetében támogatott, kivéve az általános célú v1-es vagy v2-es Storage-fiókokat a prémium szintű teljesítmény szintjén.CORS is supported for all storage account types except for general-purpose v1 or v2 storage accounts in the premium performance tier.

CORS-kérelmek ismertetéseUnderstanding CORS requests

A CORS kérése két külön kérelemből állhat:A CORS request from an origin domain may consist of two separate requests:

  • Egy elővizsgálati kérelem, amely lekérdezi a szolgáltatás által meghatározott CORS-korlátozásokat.A preflight request, which queries the CORS restrictions imposed by the service. Az elővizsgálatra vonatkozó kérést csak akkor kell megadni, ha a kérelem metódusa egyszerű módszer, azaz Get, Head vagy post.The preflight request is required unless the request method is a simple method, meaning GET, HEAD, or POST.

  • A tényleges kérelem a kívánt erőforráson.The actual request, made against the desired resource.

Elővizsgálati kérelemPreflight request

Az elővizsgálati kérelem lekérdezi azokat a CORS-korlátozásokat, amelyek a fiók tulajdonosa által a Storage szolgáltatáshoz vannak meghatározva.The preflight request queries the CORS restrictions that have been established for the storage service by the account owner. A webböngésző (vagy más felhasználói ügynök) olyan beállítási kérést küld, amely tartalmazza a kérelem fejléceit, a metódust és a forrás tartományt.The web browser (or other user agent) sends an OPTIONS request that includes the request headers, method and origin domain. A Storage szolgáltatás kiértékeli a kívánt műveletet olyan előre konfigurált CORS-szabályok alapján, amelyek meghatározzák, hogy mely forrástartomány, kérési metódusok és kérések fejlécei adhatók meg tényleges kérelemre egy tárolási erőforráson.The storage service evaluates the intended operation based on a pre-configured set of CORS rules that specify which origin domains, request methods, and request headers may be specified on an actual request against a storage resource.

Ha a CORS engedélyezve van a szolgáltatáshoz, és van egy CORS-szabály, amely megfelel az elővizsgálati kérelemnek, a szolgáltatás az 200 (OK) állapotkóddal válaszol, és tartalmazza a válaszban a szükséges hozzáférés-vezérlési fejléceket.If CORS is enabled for the service and there is a CORS rule that matches the preflight request, the service responds with status code 200 (OK), and includes the required Access-Control headers in the response.

Ha a CORS nincs engedélyezve a szolgáltatáshoz, vagy egyetlen CORS-szabály sem felel meg az elővizsgálati kérelemnek, a szolgáltatás a 403 (tiltott) állapotkódot fogja válaszolni.If CORS is not enabled for the service or no CORS rule matches the preflight request, the service will respond with status code 403 (Forbidden).

Ha a beállítások kérése nem tartalmazza a szükséges CORS-fejléceket (a forrás-és hozzáférés-vezérlés-kérelem-metódus fejléceket), a szolgáltatás a 400-as állapotkódot (hibás kérelem) fogja válaszolni.If the OPTIONS request doesn’t contain the required CORS headers (the Origin and Access-Control-Request-Method headers), the service will respond with status code 400 (Bad request).

Vegye figyelembe, hogy az elővizsgálati kérelem kiértékelése a szolgáltatás (blob, fájl, üzenetsor vagy tábla) alapján történik, és nem a kért erőforrásra.Note that a preflight request is evaluated against the service (Blob, File, Queue, or Table) and not against the requested resource. Ahhoz, hogy a kérelem sikeres legyen, a fiók tulajdonosának engedélyezve kell lennie a CORS a szolgáltatásfiók szolgáltatás tulajdonságainak részeként.The account owner must have enabled CORS as part of the account service properties in order for the request to succeed.

Tényleges kérelemActual request

Az elővizsgálati kérelem elfogadása és a válasz visszaadása után a böngésző elküldi a tényleges kérelmet a tárolási erőforrásnak.Once the preflight request is accepted and the response is returned, the browser will dispatch the actual request against the storage resource. A böngésző azonnal megtagadja a tényleges kérést, ha az elővizsgálati kérelem elutasításra kerül.The browser will deny the actual request immediately if the preflight request is rejected.

A tényleges kérést a rendszer normál kérelemként kezeli a Storage szolgáltatásban.The actual request is treated as normal request against the storage service. A forrás fejlécének jelenléte azt jelzi, hogy a kérelem CORS-kérelem, és a szolgáltatás a megfelelő CORS-szabályokat fogja ellenőriznie.The presence of the Origin header indicates that the request is a CORS request and the service will check the matching CORS rules. Ha talál egyezést, a rendszer a hozzáférés-vezérlési fejléceket hozzáadja a válaszhoz, és visszaküldi az ügyfélnek.If a match is found, the Access-Control headers are added to the response and sent back to the client. Ha nem található egyezés, a CORS hozzáférés-vezérlési fejlécek nem lesznek visszaadva.If a match is not found, the CORS Access-Control headers are not returned.

CORS engedélyezése az Azure Storage-hozEnabling CORS for Azure Storage

A CORS szabályok a szolgáltatási szinten vannak beállítva, ezért az egyes szolgáltatásokhoz (Blobok, fájlok, üzenetsor és táblák) külön engedélyezni vagy letiltani kell a CORS.CORS rules are set at the service level, so you need to enable or disable CORS for each service (Blob, File, Queue and Table) separately. Alapértelmezés szerint a CORS minden szolgáltatásban le van tiltva.By default, CORS is disabled for each service. A CORS engedélyezéséhez be kell állítania a megfelelő szolgáltatási tulajdonságokat az 2013-08-15-es vagy újabb verzióval a blob, a várólista és a Table Services, vagy a 2015-02-21-es vagy a file Service-verzióhoz.To enable CORS, you need to set the appropriate service properties using version 2013-08-15 or later for the Blob, Queue, and Table services, or version 2015-02-21 or for the File service. A CORS az CORS-szabályoknak a szolgáltatás tulajdonságaihoz való hozzáadásával engedélyezheti.You enable CORS by adding CORS rules to the service properties. A szolgáltatás CORS engedélyezésével és letiltásával, valamint a CORS szabályok beállításával kapcsolatos részletekért tekintse meg a blob szolgáltatás tulajdonságainak beállítása, a Fájlszolgáltatások tulajdonságainakbeállítása, a Table szolgáltatás tulajdonságainak beállításaés a várólista-szolgáltatás tulajdonságainakbeállítása című témakört.For details about how to enable or disable CORS for a service and how to set CORS rules, please refer to Set Blob Service Properties, Set File Service Properties, Set Table Service Properties, and Set Queue Service Properties.

Íme egy példa egyetlen CORS-szabályra, amely egy műveleten keresztül van megadva Set Service Properties :Here is a sample of a single CORS rule, specified via a Set Service Properties operation:

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com, http://www.fabrikam.com</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>  
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>  
        <MaxAgeInSeconds>200</MaxAgeInSeconds>  
    </CorsRule>  
<Cors>  
  

Az CORS-szabályban szereplő összes elemről alább olvashat:Each element included in the CORS rule is described below:

  • AllowedOrigins: azok a forrástartomány-tartományok, amelyek számára engedélyezett a CORS keresztüli kérelem küldése a Storage szolgáltatással.AllowedOrigins: The origin domains that are permitted to make a request against the storage service via CORS. A forrás tartomány az a tartomány, amelyből a kérelem származik.The origin domain is the domain from which the request originates. Vegye figyelembe, hogy a forrásnak pontos kis-és nagybetűkkel egyezőnek kell lennie azzal a forrással, amelyet a felhasználó a szolgáltatásnak küld.Note that the origin must be an exact case-sensitive match with the origin that the user age sends to the service. A "*" helyettesítő karaktert is használhatja, amely lehetővé teszi az összes forrás tartomány számára a CORS-n keresztüli kérések elvégzését.You can also use the wildcard character '*' to allow all origin domains to make requests via CORS. A fenti példában a tartományok és a http://www.contoso.com http://www.fabrikam.com CORS használatával kérelmeket tehetnek a szolgáltatással szemben.In the example above, the domains http://www.contoso.com and http://www.fabrikam.com can make requests against the service using CORS.

  • AllowedMethods: az a metódusok (http-kérési műveletek), amelyeket a forrástartomány HASZNÁLHAT egy CORS-kérelemhez.AllowedMethods: The methods (HTTP request verbs) that the origin domain may use for a CORS request. A fenti példában csak a PUT és a GET kérések engedélyezettek.In the example above, only PUT and GET requests are permitted.

  • AllowedHeaders: a CORS kérelemben a forrás tartomány által megadható kérelmek fejlécei.AllowedHeaders: The request headers that the origin domain may specify on the CORS request. A fenti példában az összes metaadat-fejléc, amely a x-ms-meta-data , a és a rendszertől kezdődően x-ms-meta-target x-ms-meta-abc engedélyezett.In the example above, all metadata headers starting with x-ms-meta-data, x-ms-meta-target, and x-ms-meta-abc are permitted. Vegye figyelembe, hogy a helyettesítő karakter (*) azt jelzi, hogy a megadott előtaggal kezdődő fejlécek engedélyezettek.Note that the wildcard character '*' indicates that any header beginning with the specified prefix is allowed.

  • ExposedHeaders: a CORS kérelemre adott válaszban és a böngésző által a kérelem kiállítója számára elérhető válasz fejlécei.ExposedHeaders: The response headers that may be sent in the response to the CORS request and exposed by the browser to the request issuer. A fenti példában a böngésző arra utasítja a böngészőt, hogy tegye elérhetővé bármely fejlécet a-től kezdődően x-ms-meta .In the example above, the browser is instructed to expose any header beginning with x-ms-meta.

  • MaxAgeInSeconds: az a maximális időtartam, ameddig egy böngésző gyorsítótárazza az elővizsgálati beállítások kérését.MaxAgeInSeconds: The maximum amount time that a browser should cache the preflight OPTIONS request.

Az Azure Storage Services támogatja a AllowedHeaders és a ExposedHeaders elemekhez tartozó előre rögzített fejlécek megadását.The Azure storage services support specifying prefixed headers for both the AllowedHeaders and ExposedHeaders elements. A fejlécek kategóriájának engedélyezéséhez megadhat egy közös előtagot az adott kategóriához.To allow a category of headers, you can specify a common prefix to that category. Ha például x-ms-meta* egy előtagként megadott fejlécet ad meg, akkor egy olyan szabályt hoz létre, amely megfelel a-val kezdődő összes fejlécnek x-ms-meta .For example, specifying x-ms-meta* as a prefixed header establishes a rule that will match all headers that begin with x-ms-meta.

A CORS-szabályokra az alábbi korlátozások vonatkoznak:The following limitations apply to CORS rules:

  • Tárolási szolgáltatás (blob, fájl, tábla és üzenetsor) esetében legfeljebb öt CORS szabályt adhat meg.You can specify up to five CORS rules per storage service (Blob, File, Table, and Queue).

  • A kérelemben szereplő összes CORS-szabály beállításainak maximális mérete (az XML-címkék kivételével) nem haladhatja meg a 2 KiB értéket.The maximum size of all CORS rules settings on the request, excluding XML tags, should not exceed 2 KiB.

  • Az engedélyezett fejlécek, a megjelenített fejlécek és a megengedett forrás hossza nem haladhatja meg a 256 karaktert.The length of an allowed header, exposed header, or allowed origin should not exceed 256 characters.

  • Az engedélyezett fejlécek és az elérhető fejlécek a következők lehetnek:Allowed headers and exposed headers may be either:

    • Literális fejlécek, ahol a pontos fejléc neve van megadva, például x-MS-meta-Processed.Literal headers, where the exact header name is provided, such as x-ms-meta-processed. A kérelemben legfeljebb 64 literál fejléc adható meg.A maximum of 64 literal headers may be specified on the request.
    • Előre meghatározott fejlécek, ahol a fejléc egy előtagját megadja, például az x-MS-meta-- * adatforrásokat.Prefixed headers, where a prefix of the header is provided, such as x-ms-meta-data*. Egy előtag ily módon történő megadásával engedélyezheti vagy közzéteheti az adott előtaggal kezdődő fejléceket.Specifying a prefix in this manner allows or exposes any header that begins with the given prefix. A kérelemben legfeljebb két előre rögzített fejléc adható meg.A maximum of two prefixed headers may be specified on the request.
  • A AllowedMethods elemben megadott metódusoknak (vagy http-műveleteknek) meg kell felelniük az Azure Storage szolgáltatás API-jai által támogatott módszereknek.The methods (or HTTP verbs) specified in the AllowedMethods element must conform to the methods supported by Azure storage service APIs. A támogatott módszerek a következők: törlés, beolvasás, fej, EGYESÍTÉS, közzététel, beállítások és PUT.Supported methods are DELETE, GET, HEAD, MERGE, POST, OPTIONS and PUT.

A CORS-szabály kiértékelési logikájának ismertetéseUnderstanding CORS rule evaluation logic

Ha egy tárolási szolgáltatás elővizsgálatot vagy tényleges kérelmet kap, akkor a rendszer a megfelelő set Service Properties művelettel a szolgáltatáshoz létrehozott CORS szabályok alapján értékeli ki a kérelmet.When a storage service receives a preflight or actual request, it evaluates that request based on the CORS rules you have established for the service via the appropriate Set Service Properties operation. A CORS-szabályok kiértékelése abban a sorrendben történik, ahogy a szolgáltatás tulajdonságainak beállítása művelet kérés törzsében lettek beállítva.CORS rules are evaluated in the order in which they were set in the request body of the Set Service Properties operation.

A CORS-szabályok kiértékelése a következőképpen történik:CORS rules are evaluated as follows:

  1. Először a rendszer a kérelem forrás tartományát ellenőrzi a elemben felsorolt tartományokban AllowedOrigins .First, the origin domain of the request is checked against the domains listed for the AllowedOrigins element. Ha a forrástartomány szerepel a listában, vagy az összes tartomány engedélyezett a "*" helyettesítő karakterrel, akkor a szabályok kiértékelése folyamatban van.If the origin domain is included in the list, or all domains are allowed with the wildcard character '*', then rules evaluation proceeds. Ha a forrástartomány nem szerepel a tartományban, a kérelem meghiúsul.If the origin domain is not included, then the request fails.

  2. Ezután a kérelem metódusa (vagy HTTP-művelete) be van jelölve az elemben felsorolt metódusokkal AllowedMethods .Next, the method (or HTTP verb) of the request is checked against the methods listed in the AllowedMethods element. Ha a metódus szerepel a listában, akkor a szabályok kiértékelése folyamatban van. Ha nem, akkor a kérelem sikertelen lesz.If the method is included in the list, then rules evaluation proceeds; if not, then the request fails.

  3. Ha a kérelem megfelel a forrás tartományában található szabálynak és a metódusának, akkor ez a szabály a kérelem feldolgozására van kiválasztva, és nincs kiértékelve további szabály.If the request matches a rule in its origin domain and its method, that rule is selected to process the request and no further rules are evaluated. A kérelem sikeressége előtt azonban a kérésben megadott fejlécek a elemben felsorolt fejlécekkel lesznek bejelölve AllowedHeaders .Before the request can succeed, however, any headers specified on the request are checked against the headers listed in the AllowedHeaders element. Ha a továbbított fejlécek nem egyeznek az engedélyezett fejlécekkel, a kérelem meghiúsul.If the headers sent do not match the allowed headers, the request fails.

Mivel a szabályok feldolgozása a kérelem törzsében található sorrendben történik, ajánlott eljárások azt javasolják, hogy a lista első részében a legszigorúbb szabályokat kell megadnia, hogy először a listán legyenek kiértékelve.Since the rules are processed in the order they are present in the request body, best practices recommend that you specify the most restrictive rules with respect to origins first in the list, so that these are evaluated first. Olyan szabályokat határozzon meg, amelyek kevésbé korlátozóak – például egy olyan szabály, amely engedélyezi az összes eredetet – a lista végén.Specify rules that are less restrictive – for example, a rule to allow all origins – at the end of the list.

Példa – CORS-szabályok kiértékeléseExample – CORS rules evaluation

A következő példa egy részleges kérelem törzsét mutatja be egy művelethez, amely CORS szabályokat állít be a tárolási szolgáltatásokhoz.The following example shows a partial request body for an operation to set CORS rules for the storage services. Lásd: a blob szolgáltatás tulajdonságainakbeállítása, a Fájlszolgáltatások tulajdonságainakbeállítása, a várólista-szolgáltatás tulajdonságainakbeállítása, valamint a Table szolgáltatás tulajdonságainak beállítása a kérelem összeállításával kapcsolatos részletekért.See Set Blob Service Properties, Set File Service Properties, Set Queue Service Properties, and Set Table Service Properties for details on constructing the request.

<Cors>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>PUT,HEAD</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>*</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>  
    </CorsRule>  
</Cors>

Ezután vegye figyelembe a következő CORS-kérelmeket:Next, consider the following CORS requests:

MetódusMethod ForrásOrigin KérésfejlécekRequest headers Szabály egyezéseRule Match EredményResult
PUTPUT http://www.contoso.com x-ms-blob-content-type Első szabályFirst rule SikeresSuccess
GETGET http://www.contoso.com x-ms-blob-content-type Második szabálySecond rule SikeresSuccess
GETGET http://www.contoso.com x-ms-client-request-id Második szabálySecond rule HibaFailure

Az első kérelem megfelel az első szabálynak – a forrás tartomány megfelel az engedélyezett eredetnek, a metódus megfelel az engedélyezett módszereknek, és a fejléc megfelel az engedélyezett fejléceknek – és így sikeres lesz.The first request matches the first rule – the origin domain matches the allowed origins, the method matches the allowed methods, and the header matches the allowed headers – and so succeeds.

A második kérelem nem felel meg az első szabálynak, mert a metódus nem felel meg az engedélyezett módszereknek.The second request does not match the first rule because the method does not match the allowed methods. Ez azonban megegyezik a második szabállyal, így az sikeres lesz.It does, however, match the second rule, so it succeeds.

A harmadik kérelem megegyezik a forrás-tartomány második szabályával és a metódussal, így nincs kiértékelve további szabály.The third request matches the second rule in its origin domain and method, so no further rules are evaluated. A x-ms-client-request-id második szabály azonban nem engedélyezi a fejlécet, így a kérés meghiúsul, annak ellenére, hogy a harmadik szabály szemantikai engedélye sikeres volt.However, the x-ms-client-request-id header is not allowed by the second rule, so the request fails, despite the fact that the semantics of the third rule would have allowed it to succeed.

Megjegyzés

Bár ez a példa egy kevésbé korlátozó szabályt mutat be, amely egy szigorúbb korlátozást mutat be, általánosságban az ajánlott eljárás az, hogy először a legszigorúbb szabályokat sorolja fel.Although this example shows a less restrictive rule before a more restrictive one, in general the best practice is to list the most restrictive rules first.

A változó fejléc beállításának ismertetéseUnderstanding how the Vary header is set

A Vary fejléc egy szabványos HTTP/1.1 fejléc, amely a kérelem fejlécében szereplő mezőkből áll, amelyek a böngésző vagy a felhasználói ügynök számára tájékoztatják a kiszolgáló által a kérelem feldolgozására kiválasztott feltételekről.The Vary header is a standard HTTP/1.1 header consisting of a set of request header fields that advise the browser or user agent about the criteria that were selected by the server to process the request. A Vary fejléc elsődlegesen a proxyk, böngészők és CDNs gyorsítótárazására használatos, amelyekkel meghatározható, hogy a válasz hogyan legyen gyorsítótárazva.The Vary header is mainly used for caching by proxies, browsers, and CDNs, which use it to determine how the response should be cached. Részletekért tekintse meg a változó fejlécspecifikációját.For details, see the specification for the Vary header.

Ha a böngésző vagy egy másik felhasználói ügynök gyorsítótárazza a választ egy CORS-kérelemből, a rendszer gyorsítótárazza a forrás tartományt a megengedett forrásként.When the browser or another user agent caches the response from a CORS request, the origin domain is cached as the allowed origin. Ha egy második tartomány egy tárolási erőforrásra vonatkozó kérelmet ad ki, miközben a gyorsítótár aktív, a felhasználói ügynök lekéri a gyorsítótárazott tartományt.When a second domain issues the same request for a storage resource while the cache is active, the user agent retrieves the cached origin domain. A második tartomány nem felel meg a gyorsítótárazott tartománynak, így a kérelem meghiúsul, ha az egyébként sikeres lenne.The second domain does not match the cached domain, so the request fails when it would otherwise succeed. Bizonyos esetekben az Azure Storage úgy állítja be a fejlécet, hogy arra Vary Origin utasítja a felhasználói ügynököt, hogy küldje el a következő CORS kérelmet a szolgáltatásnak, amikor a kérelmező tartomány eltér a gyorsítótárazott forrástól.In certain cases, Azure Storage sets the Vary header to Origin to instruct the user agent to send the subsequent CORS request to the service when the requesting domain differs from the cached origin.

Az Azure Storage a Vary következő esetekben állítja be a fejlécet a Origin tényleges Get/Head kérelmekhez:Azure Storage sets the Vary header to Origin for actual GET/HEAD requests in the following cases:

  • Ha a kérelem forrása pontosan megegyezik a CORS-szabály által meghatározott engedélyezett forrással.When the request origin exactly matches the allowed origin defined by a CORS rule. A pontos egyezés érdekében a CORS szabály nem tartalmazhat helyettesítő karaktert (*).To be an exact match, the CORS rule may not include a wildcard '*' character.

  • Nincs olyan szabály, amely megfelelne a kérelem forrásának, de a CORS engedélyezve van a tárolási szolgáltatás számára.There is no rule matching the request origin, but CORS is enabled for the storage service.

Abban az esetben, ha egy GET/HEAD kérelem megfelel egy olyan CORS-szabálynak, amely lehetővé teszi az összes eredetet, a válasz azt jelzi, hogy az összes eredet engedélyezett, és a felhasználói ügynök gyorsítótára engedélyezi a további kéréseket bármely forrás tartományból, amíg a gyorsítótár aktív.In the case where a GET/HEAD request matches a CORS rule that allows all origins, the response indicates that all origins are allowed, and the user agent cache will allow subsequent requests from any origin domain while the cache is active.

Vegye figyelembe, hogy a GET/HEAD metódustól eltérő módszereket használó kérelmek esetén a Storage szolgáltatás nem állítja be a Vary fejlécet, mert a metódusokra adott válaszokat nem a felhasználói ügynökök gyorsítótárazzák.Note that for requests using methods other than GET/HEAD, the storage services will not set the Vary header, since responses to these methods are not cached by user agents.

A következő táblázat azt mutatja be, hogy az Azure Storage hogyan válaszol a lekéréses/HEAD kérelmekre a korábban említett esetek alapján:The following table indicates how Azure storage will respond to GET/HEAD requests based on the previously mentioned cases:

A forrás fejléce szerepel a kérelembenOrigin header present on request A szolgáltatáshoz megadott CORS-szabály (ok)CORS rule(s) specified for this service Létezik olyan egyezési szabály, amely lehetővé teszi az összes eredetet ( * )Matching rule exists that allows all origins (*) A pontos egyezéshez tartozó szabály létezikMatching rule exists for exact origin match A válasz tartalmazza a változó fejlécet a forrás értékreResponse includes Vary header set to Origin A válasz tartalmazza a hozzáférés-vezérlés – engedélyezett – forrás: " * "Response includes Access-Control-Allowed-Origin: "*" A válasz tartalmazza a hozzáférés-vezérlésre feltett fejléceketResponse includes Access-Control-Exposed-Headers
NemNo NemNo NemNo NemNo NemNo NemNo NemNo
NemNo YesYes NemNo NemNo YesYes NemNo NemNo
NemNo IgenYes IgenYes NemNo NemNo IgenYes IgenYes
IgenYes NemNo NemNo NemNo NemNo NemNo NemNo
IgenYes IgenYes NoNo IgenYes IgenYes NoNo IgenYes
IgenYes IgenYes NemNo NemNo YesYes NemNo NemNo
IgenYes IgenYes IgenYes NemNo NemNo IgenYes IgenYes

CORS kérelmek számlázásaBilling for CORS requests

Az előfizetési kérelmek számlázása akkor történik meg, ha engedélyezte a CORS a fiók egyik tárolási szolgáltatásához (a blob szolgáltatás tulajdonságainakbeállítása, a várólista-szolgáltatás tulajdonságainakbeállítása, a Fájlszolgáltatások tulajdonságainakbeállítása vagy a Table szolgáltatás tulajdonságainak beállítása).Successful preflight requests are billed if you have enabled CORS for any of the storage services for your account (by calling Set Blob Service Properties, Set Queue Service Properties, Set File Service Properties, or Set Table Service Properties). A költségek csökkentése érdekében érdemes a MaxAgeInSeconds CORS-szabályok elemét nagy értékre állítani, hogy a felhasználói ügynök gyorsítótárazza a kérést.To minimize charges, consider setting the MaxAgeInSeconds element in your CORS rules to a large value so that the user agent caches the request.

A sikertelen elővizsgálati kérelmekért nem számolunk fel díjat.Unsuccessful preflight requests will not be billed.

Lásd mégSee also

W3C kereszthivatkozások erőforrás-megosztási specifikációjaW3C Cross-Origin Resource Sharing Specification