다음을 통해 공유

페이지 가져오기

  • 아티클

Put Page 작업은 페이지 blob에 일정 범위의 페이지를 기록합니다.

요청

다음과 같이 요청을 생성할 Put Page 수 있습니다. HTTPS를 사용하는 것이 좋습니다. myaccount를 스토리지 계정의 이름으로 바꿉니다.

PUT 메서드 요청 URI HTTP 버전
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1

에뮬레이트된 스토리지 서비스 요청

에뮬레이트된 스토리지 서비스에 대한 요청을 수행할 때 에뮬레이터 호스트 이름 및 Blob 서비스 포트를 로 127.0.0.1:10000지정한 다음 에뮬레이트된 스토리지 계정 이름을 지정합니다.

PUT 메서드 요청 URI HTTP 버전
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page HTTP/1.1

자세한 내용은 로컬 Azure Storage 개발에 Azurite 에뮬레이터 사용을 참조하세요.

URI 매개 변수

요청 URI에 다음과 같은 추가 매개 변수를 지정할 수 있습니다.

매개 변수 Description
timeout 선택 사항입니다. timeout 매개 변수는 초 단위로 표시됩니다. 자세한 내용은 Blob 서비스 작업에 대한 시간 제한 설정을 참조하세요.

요청 헤더

필수 및 선택적 요청 헤더는 다음 표에 설명되어 있습니다.

요청 헤더 Description
Authorization 필수 사항입니다. 권한 부여 체계, 계정 이름 및 서명을 지정합니다. 자세한 내용은 Azure Storage에 대한 요청 권한 부여를 참조하세요.
Date 또는 x-ms-date 필수 사항입니다. 요청에 대한 UTC(협정 세계시)를 지정합니다. 자세한 내용은 Azure Storage에 대한 요청 권한 부여를 참조하세요.
x-ms-version 모든 권한 있는 요청에 필요합니다. 이 요청에 사용할 작업의 버전을 지정합니다. 자세한 내용은 Azure Storage 서비스에 대한 버전 관리를 참조하세요.
Range Range 또는 x-ms-range가 필요합니다.

페이지로 기록되는 바이트 범위를 지정합니다. 시작 및 끝 범위를 모두 지정해야 합니다. 이 헤더는 HTTP/1.1 프로토콜 사양에 의해 정의됩니다.

페이지 업데이트 작업의 경우 페이지 범위는 최대 4MiB일 수 있습니다. 페이지 지우기 작업의 경우 페이지 범위는 Blob의 전체 크기 값만큼 좋을 수 있습니다.

페이지는 512바이트 경계에 맞춰야 하므로 시작 오프셋은 512의 모듈러스여야 하고 끝 오프셋은 512 –1의 모듈러스여야 합니다. 유효한 바이트 범위의 예로는 0-511, 512-1023 등이 있습니다.

Blob Storage는 헤더에 대해 Range 단일 바이트 범위만 허용하며 바이트 범위는 형식 bytes=startByte-endByte으로 지정해야 합니다.

Range 및 x-ms-range가 모두 지정된 경우 서비스에서 x-ms-range의 값이 사용됩니다. 자세한 내용은 Blob 서비스 작업에 대한 범위 헤더 지정을 참조하세요.
x-ms-range Range 또는 x-ms-range가 필요합니다.

페이지로 기록되는 바이트 범위를 지정합니다. 시작 및 끝 범위를 모두 지정해야 합니다. 이 헤더는 HTTP/1.1 프로토콜 사양에 의해 정의됩니다.

페이지 업데이트 작업의 경우 페이지 범위는 크기가 4MiB만큼 좋을 수 있습니다. 페이지 지우기 작업의 경우 페이지 범위는 blob의 전체 크기 값까지 가능합니다.

페이지는 512바이트 경계에 맞춰야 하므로 시작 오프셋은 512의 모듈러스여야 하고 끝 오프셋은 512 – 1의 모듈러스여야 합니다. 예를 들어 유효 바이트 범위는 0-511, 512-1023 등입니다.

Blob Storage는 헤더에 대해 x-ms-range 단일 바이트 범위만 허용하며 바이트 범위는 형식 bytes=startByte-endByte으로 지정해야 합니다.

Range 및 x-ms-range가 모두 지정된 경우 서비스에서 x-ms-range의 값이 사용됩니다. 자세한 내용은 Blob 서비스 작업에 대한 범위 헤더 지정 을 참조하세요.
Content-Length 필수 사항입니다. 요청 본문에 전송 중인 바이트 수를 지정합니다. 헤더가 로 x-ms-page-write 설정 clear되면 이 헤더의 값을 로 설정 0해야 합니다.
Content-MD5 선택 사항입니다. 페이지 콘텐츠의 MD5 해시입니다. 이 해시는 전송 중 페이지의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 저장소 서비스가 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다.
<br/ >참고: 이 MD5 해시는 Blob과 함께 저장되지 않습니다.

두 해시가 일치하지 않으면 작업이 실패하고 오류 코드 400(잘못된 요청)이 표시됩니다.
x-ms-content-crc64 선택 사항입니다. 페이지 콘텐츠의 CRC64 해시입니다. 이 해시는 전송 중 페이지의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 저장소 서비스가 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다.

참고: 이 CRC64 해시는 Blob과 함께 저장되지 않습니다.

두 해시가 일치하지 않으면 작업이 실패하고 오류 코드 400(잘못된 요청)이 표시됩니다.

및 x-ms-content-crc64 헤더가 Content-MD5 모두 있는 경우 요청이 400(잘못된 요청)으로 실패합니다.

이 헤더는 버전 2019-02-02 이상에서 지원됩니다.
x-ms-page-write: {update ¦ clear} 필수 사항입니다. 다음 옵션 중 하나를 지정할 수 있습니다.

- Update: 요청 본문에 지정된 바이트를 지정된 범위에 씁니다. 업데이트를 수행하려면 Range 및 Content-Length 헤더가 일치해야 합니다.
- Clear: 지정된 범위를 지우고 해당 범위에 대한 스토리지에 사용되는 공간을 해제합니다. 범위를 지우려면 헤더0를 Content-Length 로 설정하고 헤더를 최대 Blob 크기까지 지울 범위를 나타내는 값으로 설정합니다Range.
x-ms-encryption-scope 선택 사항입니다. 요청 내용을 암호화하는 데 사용할 암호화 scope 나타냅니다. 이 헤더는 버전 2019-02-02 이상에서 지원됩니다.
x-ms-lease-id:<ID> blob에 활성 임대가 포함된 경우 필수입니다. 활성 임대가 포함된 blob에서 이 작업을 수행하려면 이 헤더에 대해 유효한 임대 ID를 지정합니다.
x-ms-if-sequence-number-le: <num> 선택 사항입니다. Blob의 시퀀스 번호가 지정된 값보다 작거나 같으면 요청이 진행됩니다. 그렇지 않으면 SequenceNumberConditionNotMet 오류(HTTP 상태 코드 412 – 사전 조건 실패)로 인해 실패합니다.
x-ms-if-sequence-number-lt: <num> 선택 사항입니다. Blob의 시퀀스 번호가 지정된 값보다 작으면 요청이 진행됩니다. 그렇지 않으면 SequenceNumberConditionNotMet 오류(HTTP 상태 코드 412 – 사전 조건 실패)로 인해 실패합니다.
x-ms-if-sequence-number-eq: <num> 선택 사항입니다. Blob의 시퀀스 번호가 지정된 값과 같으면 요청이 진행됩니다. 그렇지 않으면 SequenceNumberConditionNotMet 오류(HTTP 상태 코드 412 – 사전 조건 실패)로 인해 실패합니다.
If-Modified-Since 선택 사항입니다. DateTime 값입니다. 지정된 날짜/시간 이후 blob가 수정된 경우에만 페이지를 기록하려면 이 조건부 헤더를 지정합니다. Blob이 수정되지 않은 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다.
If-Unmodified-Since 선택 사항입니다. DateTime 값입니다. 지정된 날짜/시간 이후 Blob이 수정되지 않은 경우에만 페이지를 작성하려면 이 조건부 헤더를 지정합니다. Blob이 수정된 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다.
If-Match 선택 사항입니다. ETag 값입니다. blob의 ETag 값이 지정된 값과 일치하는 경우에만 페이지를 기록하도록 이 조건부 헤더에 대한 ETag 값을 지정합니다. 값이 일치하지 않으면 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다.
If-None-Match 선택 사항입니다. ETag 값입니다.

Blob의 ETag 값이 지정된 값과 일치하지 않는 경우에만 페이지를 작성하려면 이 조건부 헤더에 ETag 값을 지정합니다. 값이 동일하면 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다.
x-ms-client-request-id 선택 사항입니다. 로깅이 구성될 때 로그에 기록되는 1키비바이트(KiB) 문자 제한으로 클라이언트에서 생성된 불투명 값을 제공합니다. 이 헤더를 사용하여 클라이언트 쪽 활동과 서버가 수신하는 요청의 상관 관계를 지정하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage 모니터링을 참조하세요.

이 작업은 또한 지정된 조건이 충족될 경우에만 작업을 실행하는 조건부 헤더 사용을 지원합니다. 자세한 내용은 Blob 서비스 작업에 대한 조건부 헤더 지정을 참조하세요.

요청 헤더(고객이 제공한 암호화 키)

버전 2019-02-02를 기준으로 요청에서 다음 헤더를 지정하여 고객이 제공한 키로 Blob을 암호화할 수 있습니다. 고객이 제공한 키(및 해당 헤더 집합)를 사용하여 암호화하는 것은 선택 사항입니다.

요청 헤더 Description
x-ms-encryption-key 필수 사항입니다. Base64로 인코딩된 AES-256 암호화 키입니다.
x-ms-encryption-key-sha256 필수 사항입니다. 암호화 키의 Base64로 인코딩된 SHA256 해시입니다.
x-ms-encryption-algorithm: AES256 필수 사항입니다. 암호화에 사용할 알고리즘을 지정합니다. 이 헤더의 값은 AES256이어야 합니다.

요청 본문

요청 본문에는 페이지 콘텐츠가 포함됩니다.

샘플 요청: 바이트 범위 업데이트

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:  
x-ms-page-write: update  
x-ms-date: Fri, 16 Sep 2011 22:15:50 GMT  
x-ms-version: 2011-08-18  
x-ms-range: bytes=0-65535  
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=  
Content-Length: 65536

샘플 요청: 바이트 범위 지우기

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:  
Range: bytes=1024-2048  
x-ms-page-write: clear  
x-ms-date: Sun, 25 Sep 2011 23:37:35 GMT  
x-ms-version: 2011-08-18  
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=

응답

응답에는 HTTP 상태 코드 및 응답 헤더 집합이 포함되어 있습니다.

상태 코드

작업에 성공하면 상태 코드 201(만들어짐)이 반환됩니다.

상태 코드에 대한 자세한 내용은 상태 및 오류 코드를 참조하세요.

응답 헤더

이 작업의 응답에는 다음과 같은 헤더가 포함됩니다. 또한 응답에 추가 표준 HTTP 헤더가 포함될 수도 있습니다. 모든 표준 헤더는 HTTP/1.1 프로토콜 사양을 준수합니다.

구문 Description
ETag blob의 ETag입니다. 요청 버전이 2011-08-18 이상인 경우 ETag 값은 따옴표로 묶입니다. ETag를 사용하면 If-Match 또는 If-None-Match 요청 헤더에 대한 값을 지정하여 조건부 Put Page 작업을 수행할 수 있습니다.
Last-Modified Blob이 마지막으로 수정된 날짜 및 시간입니다. 날짜 형식은 RFC 1123을 따릅니다. 자세한 내용은 머리글의 날짜/시간 값 표시를 참조하세요.

blob의 메타데이터 또는 속성에 대한 업데이트를 포함하여 blob에 대해 쓰기 작업을 수행할 때마다 blob의 마지막 수정 시간이 변경됩니다.
Content-MD5 이 헤더는 클라이언트가 메시지 콘텐츠 무결성을 확인할 수 있도록 반환됩니다. 이 헤더의 값은 Blob Storage에서 계산됩니다. 반드시 요청 헤더에 지정된 값과 동일하지는 않습니다. 버전 2019-02-02 이상에서는 요청에 이 헤더가 있는 경우에만 이 헤더가 반환됩니다.
x-ms-content-crc64 버전 2019-02-02 이상에서는 클라이언트가 메시지 콘텐츠 무결성을 검사 수 있도록 이 헤더가 반환됩니다. 이 헤더의 값은 Blob Storage에서 계산됩니다. 반드시 요청 헤더에 지정된 값과 동일하지는 않습니다.

이 헤더는 헤더가 요청에 없을 때 Content-MD5 반환됩니다.
x-ms-blob-sequence-number 페이지 blob의 현재 시퀀스 번호입니다.
x-ms-request-id 만들어진 요청을 고유하게 식별하며 요청 문제를 해결하는 데 사용할 수 있습니다. 자세한 내용은 API 작업 문제 해결을 참조하세요.
x-ms-version 요청을 실행하는 데 사용된 Blob 서비스 버전을 나타냅니다. 이 헤더는 버전 2009-09-19 이상에 대해 수행된 요청에 대해 반환됩니다.
Date 서비스에서 생성된 UTC 날짜/시간 값으로, 응답이 시작된 시간을 나타냅니다.
x-ms-request-server-encrypted: true/false 버전 2015-12-11 이상. 지정된 알고리즘을 true 사용하여 요청 내용이 성공적으로 암호화되면 이 헤더의 값이 로 설정됩니다. 지역화할 수 없으면 이 값은 false로 설정됩니다.
x-ms-encryption-key-sha256 버전 2019-02-02 이상. 요청에서 고객이 제공한 키를 암호화에 사용한 경우 반환되므로 클라이언트는 제공된 키를 사용하여 요청 내용이 성공적으로 암호화되도록 할 수 있습니다.
x-ms-encryption-scope 버전 2019-02-02 이상. 요청이 암호화 scope 사용한 경우 반환되므로 클라이언트는 암호화 scope 사용하여 요청 내용이 성공적으로 암호화되도록 할 수 있습니다.
x-ms-client-request-id 요청 및 해당 응답 문제를 해결하는 데 사용할 수 있습니다. 이 헤더의 값 x-ms-client-request-id 은 요청에 있고 값에 표시되는 ASCII 문자가 1,024자 이하인 경우 헤더 값과 같습니다. 헤더가 x-ms-client-request-id 요청에 없으면 응답에 표시되지 않습니다.

응답 본문

없음

샘플 응답

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 22:33:35 GMT  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: Sun, 25 Sep 2011 12:13:31 GMT  
x-ms-version: 2011-08-18  
x-ms-blob-sequence-number: 0  
Content-Length: 0  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

권한 부여

Azure Storage에서 데이터 액세스 작업을 호출할 때 권한 부여가 필요합니다. 아래에 설명된 대로 작업에 권한을 부여할 Put Page 수 있습니다.

중요

Microsoft는 관리 ID와 함께 Microsoft Entra ID 사용하여 Azure Storage에 대한 요청에 권한을 부여하는 것이 좋습니다. Microsoft Entra ID 공유 키 권한 부여에 비해 뛰어난 보안 및 사용 편의성을 제공합니다.

Azure Storage는 Microsoft Entra ID 사용하여 Blob 데이터에 대한 요청에 권한을 부여할 수 있도록 지원합니다. Microsoft Entra ID 사용하면 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 보안 주체에 권한을 부여할 수 있습니다. 보안 주체는 사용자, 그룹, 애플리케이션 서비스 주체 또는 Azure 관리 ID일 수 있습니다. 보안 주체는 Microsoft Entra ID 인증되어 OAuth 2.0 토큰을 반환합니다. 그런 다음 토큰을 사용하여 Blob service에 대한 요청을 승인할 수 있습니다.

Microsoft Entra ID 사용하여 권한 부여에 대한 자세한 내용은 Microsoft Entra ID 사용하여 Blob에 대한 액세스 권한 부여를 참조하세요.

사용 권한

아래에는 Microsoft Entra 사용자, 그룹, 관리 ID 또는 서비스 주체가 작업을 호출 Put Page 하는 데 필요한 RBAC 작업과 이 작업을 포함하는 최소 권한의 기본 제공 Azure RBAC 역할이 나와 있습니다.

Azure RBAC를 사용하여 역할을 할당하는 방법에 대한 자세한 내용은 Blob 데이터에 액세스하기 위해 Azure 역할 할당을 참조하세요.

설명

Put Page 작업은 페이지 blob에 일정 범위의 페이지를 기록합니다. 이 작업은 기존 페이지 Blob에서만 호출할 수 있습니다. 새 페이지 Blob을 만들기 위해 호출할 수 없으며 블록 Blob에서 호출할 수도 없습니다. 현재 존재하지 않는 Blob 이름으로 를 호출 Put Page 하면 HTTP 상태 코드 404(찾을 수 없음)가 반환됩니다.

새 페이지 Blob을 만들려면 Blob 배치 를 호출하고 페이지 Blob으로 만들 Blob 유형을 지정합니다. 페이지 Blob의 크기는 최대 8TiB입니다.

Blob에 활성 임대가 있는 경우 클라이언트는 페이지 작성 요청에 유효한 임대 ID를 지정해야 합니다.

페이지 업데이트 작업

Update 옵션을 사용하여 Put Page를 호출하면 지정된 페이지 blob에서 내부 쓰기가 수행됩니다. 업데이트를 수행하면 지정된 페이지의 콘텐츠를 덮어씁니다.

중요

서버 시간이 초과되거나 작업 중에 Put Page 연결이 닫힌 경우 페이지가 업데이트되었을 수도 있고 업데이트되지 않았을 수도 있습니다. 따라서 성공을 나타내는 응답을 받을 때까지 업데이트를 계속 다시 시도해야 합니다.

업데이트 작업을 위해 제출된 Put Page 각 페이지 범위의 크기는 최대 4MiB일 수 있습니다. 이 페이지의 시작 및 끝 범위는 512바이트 경계로 정렬되어야 합니다. 4MiB보다 큰 페이지 범위를 업로드하려고 하면 서비스는 상태 코드 413(엔터티 너무 큰 요청)을 반환합니다.

페이지 지우기 작업

옵션을 사용하여 Clear 를 호출 Put Page 하면 지정된 페이지에서 사용하는 스토리지 공간이 해제됩니다. 지워진 페이지는 더 이상 페이지 blob의 일부로 추적되지 않습니다.

지워진 페이지는 스토리지 리소스가 릴리스되었기 때문에 스토리지 계정에 대한 요금이 더 이상 발생하지 않습니다. 유일한 예외는 페이지 Blob의 기존 스냅샷이 있는 경우입니다. 스냅샷의 페이지는 원본 Blob의 일부로 동일한 페이지가 더 이상 존재하지 않는 경우 요금이 부과됩니다.

동시성 문제 관리

Blob Storage는 겹치는 페이지에 대한 동시 쓰기를 순차적으로 처리합니다. 즉, 서비스에서 처리한 마지막 페이지에서 Blob의 콘텐츠를 결정합니다. 따라서 Blob 콘텐츠의 무결성을 보장하기 위해 클라이언트는 다음 방법 중 하나 이상을 사용하여 겹치는 페이지에 대한 쓰기를 처리해야 합니다.

  • Put Page에 대해 성공한 각 호출에 대해 Last-Modified 응답 헤더 값을 확인할 수 있습니다. Blob Storage에서 반환된 응답 순서가 서비스에서 실행된 순서와 반드시 일치하지는 않습니다. 하지만 Last-Modified 값은 항상 서비스가 요청을 처리한 순서를 나타냅니다.

  • 낙관적 동시성을 사용해서 blob의 ETag 또는 마지막으로 수정된 시간에 따라 조건부로 업데이트를 수행할 수 있습니다. 이 방법은 동시 쓰기 작업 수가 비교적 적은 경우에 적합합니다. 이 목적을 위해서는 조건부 요청 헤더 If-Match, If-None-Match, If-Modified-Since 및 If-Unmodified-Since를 사용합니다.

  • 임대 Blob을 호출하여 1분 동안 또는 임대가 갱신된 경우 더 이상 다른 쓰기에 대해 Blob을 잠글 수 있습니다.

  • Blob의 시퀀스 번호를 사용하여 응답이 없는 요청을 다시 시도해도 동시 업데이트가 발생하지 않도록 할 수 있습니다. 이 방법은 페이지 쓰기에 높은 처리량이 필요한 클라이언트에 가장 적합할 수 있습니다. 이 내용은 다음 섹션에서 자세히 설명합니다.

페이지 Blob 시퀀스 번호를 사용하여 요청 다시 시도

호출 Put Page 시간이 초과되거나 응답을 반환하지 않는 경우 요청이 성공했는지 여부를 확실히 알 수 있는 방법이 없습니다. 따라서 요청을 다시 시도해야 하지만 Azure Storage 서비스의 분산 특성으로 인해 다시 시도된 요청이 성공한 후 원래 요청이 처리될 수 있습니다. 그 결과 지연되었던 원래 요청이 업데이트된 다른 항목을 덮어써서 예기치 않은 결과가 발생할 수 있습니다. 다음 시퀀스는 이러한 문제가 발생하는 방법을 보여 줍니다.

  1. Put Page 0페이지에 값 "X"를 쓰거나 응답을 반환하지 않는 요청입니다.

  2. 페이지 0에 값 "X"를 쓰려는 다시 시도된 요청이 성공합니다.

  3. 페이지 0에 값 "Y"를 쓰려는 요청이 성공합니다.

  4. 원래 요청이 성공하여 페이지 0에 값 "X"가 기록됩니다.

  5. 이제 클라이언트에 값 "Y"가 포함되어야 하지만 페이지 0을 읽으면 값 "X"가 반환됩니다.

이러한 종류의 충돌은 원래 요청이 상태 코드를 100에서 499 또는 503(서버 사용 중)으로 반환하지 않을 때 발생할 수 있습니다. 이러한 상태 코드 중 하나가 반환되면 해당 요청이 성공 또는 실패했는지를 확인할 수 있습니다. 하지만 서비스가 이 범위 이외의 상태 코드를 반환하면 원래 요청의 상태를 확인할 수 있는 방법이 없습니다.

이러한 종류의 충돌을 방지하려면 페이지 Blob의 시퀀스 번호를 사용하여 요청을 다시 시도할 때 원래 요청이 성공하지 않도록 할 수 있습니다. 이렇게 하려면 원래 요청을 다시 시도하기 전에 시퀀스 번호를 증분해야 합니다. 그런 다음 조건부 시퀀스 번호 헤더를 사용하여 시퀀스 번호가 예상 시퀀스 번호와 일치하지 않으면 요청이 실패하도록 할 수 있습니다. 다음 시퀀스에서는 이러한 방법을 보여줍니다.

  1. 클라이언트는 Put Blob 을 사용하여 페이지 Blob을 만들고 해당 시퀀스 번호를 로 0설정합니다.

  2. 헤더가 Put Page 시간 초과로 설정되거나 응답을 반환하지 않는 페이지 0에 if-sequence-number-lt1 값 "X"를 쓰는 요청입니다.

  3. 클라이언트는 를 호출 Set Blob Properties 하여 시퀀스 번호를 로 업데이트합니다 1.

  4. 값 "X"를 로 설정된 2 0 if-sequence-number-lt 페이지에 쓰는 재시도된 요청이 성공합니다.

  5. 로 설정된 2 0 if-sequence-number-lt 페이지에 값 "Y"를 쓰는 요청이 성공합니다.

  6. 원래 요청은 마침내 처리되지만 시퀀스 번호가 1보다 작아야 한다는 조건(즉, if-sequence-num-lt 헤더가 로 설정 1됨)을 지정하기 때문에 실패합니다. 오류는 SequenceNumberConditionNotMet(HTTP 상태 코드 412 – 전제 조건 실패)입니다.

  7. 페이지 0을 읽으면 예상한 대로 값 "Y"가 반환됩니다.

추가 정보

Azure Storage에 대한 요청 권한 부여
상태 및 오류 코드
Blob 서비스 작업에 대한 시간 제한 설정