預檢 Blob 要求

發行項
02/12/2024

作業會Preflight Blob Request先查詢跨原始來源資源分享 (CORS) 規則，以取得 Azure Blob 儲存體，然後再傳送要求。

網頁瀏覽器或其他使用者代理程式會傳送預檢要求，其中包含代理程式想要提出之要求的源網域、方法和標頭。如果已啟用 Blob 記憶體的 CORS，則 Blob 記憶體會根據帳戶擁有者透過設定 Blob 服務屬性設定的 CORS 規則評估預檢要求。 Blob 記憶體接著會接受或拒絕要求。

如需 CORS 和預檢要求的詳細資訊，請參閱 Azure 記憶體的 CORS 規格和 CORS 支援。

要求

您可以依照下列方式指定 Preflight Blob Request 。使用您的儲存體帳戶名稱取代 <account-name>。將取代 <blob-resource> 為將做為要求目標的容器或 Blob 資源。

HTTP 指令動詞	要求 URI	HTTP 版本
`OPTIONS`	`http://<account-name>.blob.core.windows.net/<blob-resource>`	HTTP/1.1

URI 必須一律包含 / (/) 的正斜線，以分隔主機名與 URI 的路徑和查詢部分。在此作業的情況下，URI 的路徑部分可以是空的，也可以指向任何容器或 Blob 資源。

資源在提出預檢要求時可能或可能不存在。預檢要求會根據服務的 CORS 規則在服務層級進行評估，因此資源名稱的存在或不存在不會影響作業的成功或失敗。

URI 參數

無。

要求標頭

下表描述必要和選擇性的要求標頭：

要求標頭	描述
`Origin`	必要。指定發出要求的來源。系統會根據服務的 CORS 規則檢查此來源以判斷預檢要求成功或失敗。
`Access-Control-Request-Method`	必要。指定要求的方法 (或 HTTP 動詞) 。系統會根據服務的 CORS 規則檢查此方法以判斷預檢要求失敗或成功。
`Access-Control-Request-Headers`	選擇性。指定要傳送的要求標頭。如果不存在，服務會假設要求不包含標頭。

要求本文

無。

回應

回應包括 HTTP 狀態碼和一組回應標頭。

狀態碼

成功的作業會傳回狀態碼 200 (OK)。

如需狀態代碼的相關信息，請參閱狀態和錯誤碼。

回應標頭

這項作業的回應包括下列標頭。回應也可能包含額外的標準 HTTP 標頭。所有標準標頭都符合 HTTP/1.1 通訊協議規格。

如需預檢要求標頭的詳細資訊，請參閱 CORS規格。

回應標頭	描述
`Access-Control-Allow-Origin`	指出允許的來源，如果預檢要求成功，則會比對要求中的源標頭。
`Access-Control-Allow-Methods`	如果預檢要求成功，此標頭會設定為為要求標頭 `Access-Control-Request-Method`所指定的值或值。
`Access-Control-Allow-Headers`	如果預檢要求成功，此標頭會設定為為要求標頭 `Access-Control-Request-Headers`所指定的值或值。
`Access-Control-Max-Age`	指定允許使用者代理程式快取未來要求的預檢要求時間長度。
`Access-Control-Allow-Credentials`	指出是否可以透過認證提出要求。此標頭一律設定為 `true`。

回應本文

無。

授權

作業 Preflight Blob Request 一律會以匿名方式執行。它不需要授權，而且如果提供認證，則會忽略認證。

注意

如果您已啟用 Azure 記憶體分析並記錄計量，則會將作業的 Preflight Blob Request 呼叫記錄為 AnonymousSuccess。基於這個理由，如果您在 Azure 入口網站中檢視計量，您會看到 AnonymousSuccess 記錄的 Preflight Blob Request。此計量不表示您的私人數據已遭入侵，但只有 Preflight Blob Request 作業成功，狀態代碼為 200 (OK) 。

範例要求與回應

下列範例會傳送來源 www.contoso.com的預檢要求。要求方法會設定為 PUT，而要求標頭會設定為 content-type 和 accept。

OPTIONS http://myaccount.blob.core.windows.net/mycontainer/myblockblob  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

回應指出服務已啟用 CORS，且 CORS 規則符合預檢要求：

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

備註

如果已啟用服務的 CORS，且 CORS 規則符合預檢要求，服務就會響應狀態代碼為 200 (OK) 的預檢要求。回應包含所需的 Access-Control 標頭。在此情況下，要求會計費。

如果未啟用 CORS 或 CORS 規則不符合預檢要求，服務會以狀態碼 403 (禁止) 回應。在此情況下，不會收取要求的費用。

OPTIONS如果要求格式不正確，服務會以狀態代碼 400 (不正確的要求) 回應，而且不會收取要求費用。格式錯誤的要求範例是不包含必要 Origin 和 Access-Control-Request-Method 標頭的要求。

預檢要求是查詢與特定記憶體帳戶相關聯之記憶體服務的CORS功能的機制。預檢要求不會針對特定資源。

計費

定價要求可能源自使用 Blob 記憶體 API 的用戶端，無論是直接透過 Blob 記憶體 REST API，還是來自 Azure 記憶體用戶端連結庫。這些要求會累算每個交易的費用。交易類型會影響帳戶的收費方式。例如，讀取交易會累算到與寫入交易不同的計費類別。下表根據記憶體帳戶類型顯示要求的計費類別 Preflight Blob Request ：

作業	儲存體帳戶類型	計費類別
預檢 Blob 要求	進階區塊 Blob 標準一般用途 v2	其他作業
預檢 Blob 要求	標準一般用途 v1	讀取作業

若要瞭解指定計費類別的定價，請參閱 Azure Blob 儲存體定價。

另請參閱

帳戶上的作業 (Blob 記憶體)
Azure 記憶體的 CORS 支援