URL에서 Blob 배치
Put Blob From URL
작업은 지정된 URL에서 Blob의 내용을 읽는 새 블록 Blob을 만듭니다. 이 API는 버전 2020-04-08을 기준으로 사용할 수 있습니다.
부분 업데이트는 Put Blob From URL
지원되지 않습니다. 기존 Blob의 콘텐츠는 새 Blob의 내용으로 덮어씁니다. 원본 URL을 사용하여 블록 Blob의 콘텐츠에 대한 부분 업데이트를 수행하려면 Put Block List
함께 Put Block From URL
API를 사용합니다.
원본 Blob의 크기는 최대 길이 5,000 Mebibytes(MiB)가 될 수 있습니다.
요청
다음과 같이 Put Blob From URL
생성할 수 있습니다. HTTPS를 사용하는 것이 좋습니다.
myaccount 스토리지 계정 이름으로 바꿉니다.
PUT 메서드 요청 URI | HTTP 버전 |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob |
HTTP/1.1 |
에뮬레이트된 스토리지 서비스 요청
에뮬레이트된 스토리지 서비스에 대해 요청하는 경우 에뮬레이터 호스트 이름 및 Blob 서비스 포트를 127.0.0.1:10000
지정한 다음 에뮬레이트된 스토리지 계정 이름을 지정합니다.
PUT 메서드 요청 URI | HTTP 버전 |
---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob |
HTTP/1.1 |
스토리지 에뮬레이터는 최대 2gibibytes(GiB)의 Blob 크기만 지원합니다.
자세한 내용은 로컬 Azure Storage 개발Azurite 에뮬레이터를 사용합니다.
URI 매개 변수
요청 URI에 다음과 같은 추가 매개 변수를 지정할 수 있습니다.
매개 변수 | 묘사 |
---|---|
timeout |
선택적.
timeout 매개 변수는 초 단위로 표현됩니다. 자세한 내용은 Blob Service 작업대한 시간 제한 설정을 참조하세요. |
요청 헤더
필수 및 선택적 요청 헤더는 다음 표에 설명되어 있습니다.
요청 헤더 | 묘사 |
---|---|
Authorization |
필수. 권한 부여 체계, 계정 이름 및 서명을 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요. |
Date 또는 x-ms-date |
필수. 요청에 대한 UTC(협정 세계시)를 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요. |
x-ms-version |
모든 권한 있는 요청에 필요합니다. 이 요청에 사용할 작업의 버전을 지정합니다. 자세한 내용은 Azure Storage 서비스대한 |
Content-Length |
필수. 요청 본문에서 전송되는 바이트 수를 지정합니다. 이 헤더의 값은 0으로 설정해야 합니다. 길이가 0이 아닌 경우 상태 코드 400(잘못된 요청)으로 작업이 실패합니다. |
x-ms-copy-source:name |
필수. 원본 Blob의 URL을 지정합니다. 값은 Blob을 지정하는 최대 2키비바이트(KiB)의 URL일 수 있습니다. 값은 요청 URI에 표시될 때 URL로 인코딩되어야 합니다. 원본 Blob은 공용이거나 공유 액세스 서명을 통해 권한을 부여받아야 합니다. 원본 Blob이 공용인 경우 작업을 수행하기 위해 권한 부여가 필요하지 않습니다. 원본 Blob의 크기가 5000MiB보다 크거나 원본이 유효한 Content-Length 값을 반환하지 않으면 요청이 상태 코드 409(충돌)로 실패합니다. 다음은 원본 개체 URL의 몇 가지 예입니다.- https://myaccount.blob.core.windows.net/mycontainer/myblob - https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime> - https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime> |
x-ms-copy-source-authorization: <scheme> <signature> |
선택적. 복사 원본에 대한 권한 부여 체계 및 서명을 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요. 참고: Microsoft Entra에 대해 전달자 스키마만 지원됩니다. 참고: 원본 개체가 공개적으로 액세스할 수 있거나 원본 개체가 스토리지 계정에 있고 x-ms-copy-source:name 전달되는 SAS 토큰을 사용하는 경우 이 헤더가 필요하지 않습니다.이 헤더는 버전 2020-10-02 이상에서 지원됩니다. |
x-ms-blob-type: BlockBlob |
필수. 만들 Blob의 형식을 지정합니다. 이 형식은 BlockBlob 합니다. Blob 형식이 BlockBlob 않으면 상태 코드 400(잘못된 요청)으로 작업이 실패합니다. |
Content-Type |
선택적. Blob의 MIME 콘텐츠 형식입니다. 기본 형식은 application/octet-stream . |
Content-Encoding |
선택적. Blob에 적용된 콘텐츠 인코딩을 지정합니다. 이 값은 blob 리소스에서 Blob 가져오기 작업을 수행할 때 클라이언트에 반환됩니다. 이 값이 반환되면 클라이언트는 이 값을 사용하여 Blob 콘텐츠를 디코딩할 수 있습니다. |
Content-Language |
선택적. 이 리소스에서 사용하는 자연어를 지정합니다. |
Cache-Control |
선택적. Blob Storage는 이 값을 저장하지만 사용하거나 수정하지는 않습니다. |
x-ms-source-content-md5 |
선택적. URI에서 Blob 콘텐츠의 MD5 해시입니다. 이 해시는 URI에서 데이터를 전송하는 동안 Blob의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 스토리지 서비스는 복사 원본에서 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다. 이 헤더를 생략하면 Blob Storage는 MD5 해시를 생성합니다. 두 해시가 일치하지 않으면 오류 코드 400(잘못된 요청)으로 인해 작업이 실패합니다. |
x-ms-content-crc64 |
선택적. Blob 콘텐츠의 CRC64 해시입니다. 이 해시는 전송 중에 Blob의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 스토리지 서비스는 전송된 해시에 대해 도착한 해시를 확인합니다. 두 해시가 일치하지 않으면 오류 코드 400(잘못된 요청)으로 인해 작업이 실패합니다. 이 헤더는 버전 02-02-2019 이상에서 지원됩니다. Content-MD5 및 x-ms-content-crc64 헤더가 모두 있는 경우 요청은 400(잘못된 요청)으로 실패합니다. |
x-ms-blob-content-type |
선택적. Blob의 콘텐츠 형식을 설정합니다. |
x-ms-blob-content-encoding |
선택적. Blob의 콘텐츠 인코딩을 설정합니다. |
x-ms-blob-content-language |
선택적. Blob의 콘텐츠 언어를 설정합니다. |
x-ms-blob-content-md5 |
선택적. Blob의 MD5 해시를 설정합니다. |
x-ms-blob-cache-control |
선택적. Blob의 캐시 컨트롤을 설정합니다. |
x-ms-meta-name:value |
선택적. Blob과 메타데이터로 연결된 이름-값 쌍입니다. |
x-ms-encryption-scope |
선택적. 요청 콘텐츠를 암호화하는 데 사용할 암호화 범위입니다. 이 헤더는 버전 2019-02-02 이상에서 지원됩니다. |
x-ms-tags |
선택적. Blob에서 지정된 쿼리 문자열로 인코딩된 태그를 설정합니다. 자세한 내용은 주의 섹션으로 이동하세요. 버전 2019-12-12 이상에서 지원됩니다. |
x-ms-copy-source-tag-option |
선택적. 가능한 값은 REPLACE 또는 COPY(대/소문자 구분)입니다. 기본값은 REPLACE입니다. COPY를 지정하면 원본 Blob의 태그가 대상 Blob에 복사됩니다. 원본 Blob은 프라이빗이어야 하며, 요청은 원본 Blob에서 blob 태그 가져오기를 REPLACE는 대상 Blob의 x-ms-tags 헤더로 지정된 태그를 설정합니다. REPLACE를 사용하고 x-ms-tags 태그를 지정하지 않으면 대상 Blob에 태그가 설정되지 않습니다. COPY 및 x-ms-tags 지정하면 409(충돌)가 발생합니다.버전 2021-04-10 이상에서 지원됩니다. |
x-ms-copy-source-blob-properties |
선택적. 원본 Blob 속성 복사 동작을 지정합니다.
True 설정하면 원본 Blob의 속성이 새 Blob에 복사됩니다. 기본값은 True . |
x-ms-source-if-modified-since |
선택적.
DateTime 값입니다. 지정된 날짜/시간 이후 원본 Blob이 수정된 경우에만 Blob을 배치하도록 이 조건부 헤더를 지정합니다. 원본 Blob이 수정되지 않은 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. 원본이 Azure Files 공유인 경우 이 헤더를 지정할 수 없습니다. |
x-ms-source-if-unmodified-since |
선택적.
DateTime 값입니다. 지정된 날짜/시간 이후 원본 Blob이 수정되지 않은 경우에만 Blob을 배치하도록 이 조건부 헤더를 지정합니다. 원본 Blob이 수정된 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. 원본이 Azure Files 공유인 경우 이 헤더를 지정할 수 없습니다. |
x-ms-source-if-match |
선택적. ETag 값입니다. ETag가 지정된 값과 일치하는 경우에만 원본 Blob을 배치하도록 이 조건부 헤더를 지정합니다. ETag 값이 일치하지 않으면 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. 원본이 Azure Files 공유인 경우 이 헤더를 지정할 수 없습니다. |
x-ms-source-if-none-match |
선택적. ETag 값입니다. ETag가 지정된 값과 일치하지 않는 경우에만 Blob을 배치하도록 이 조건부 헤더를 지정합니다. 값이 동일하면 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. 원본이 Azure Files 공유인 경우 이 헤더를 지정할 수 없습니다. |
If-Modified-Since |
선택적.
DateTime 값입니다. 지정된 날짜/시간 이후 대상 Blob이 수정된 경우에만 Blob을 배치하도록 이 조건부 헤더를 지정합니다. 대상 Blob이 수정되지 않은 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. |
If-Unmodified-Since |
선택적.
DateTime 값입니다. 지정된 날짜/시간 이후 대상 Blob이 수정되지 않은 경우에만 Blob을 배치하도록 이 조건부 헤더를 지정합니다. 대상 Blob이 수정된 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. |
If-Match |
선택적. ETag 값입니다. 지정된 ETag 값이 기존 대상 Blob의 ETag 값과 일치하는 경우에만 Blob을 배치하도록 이 조건부 헤더에 대한 ETag 값을 지정합니다. 대상 Blob의 ETag가 If-Match 지정된 ETag와 일치하지 않으면 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. |
If-None-Match |
선택적. ETag 값 또는 와일드카드 문자(*)입니다. 지정된 ETag 값이 대상 Blob의 ETag 값과 일치하지 않는 경우에만 Blob을 배치하도록 이 조건부 헤더에 대한 ETag 값을 지정합니다. 대상 Blob이 없는 경우에만 작업을 수행하도록 와일드카드 문자(*)를 지정합니다. 지정된 조건이 충족되지 않으면 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. |
x-ms-lease-id:<ID> |
Blob에 활성 임대가 있는 경우 필요합니다. 활성 임대가 있는 Blob에서 이 작업을 수행하려면 이 헤더에 유효한 임대 ID를 지정합니다. |
x-ms-blob-content-disposition |
선택적. Blob의 Content-Disposition 헤더를 설정합니다. 버전 2013-08-15 이상에 사용할 수 있습니다.Content-Disposition 응답 헤더 필드는 응답 페이로드를 처리하는 방법에 대한 추가 정보를 전달하며 추가 메타데이터를 연결하는 데 사용할 수 있습니다. 예를 들어 헤더가 attachment 설정되면 사용자 에이전트가 응답을 표시해서는 안 되었음을 나타냅니다. 대신 지정된 Blob 이름이 아닌 파일 이름을 사용하여 다른 이름으로 저장 대화 상자를 표시해야 합니다.Blob 가져오기 및 Blob 속성 가져오기 작업의 응답에는 content-disposition 헤더가 포함됩니다. |
Origin |
선택적. 요청이 발급되는 원본을 지정합니다. 이 헤더가 있으면 응답에 CORS(원본 간 리소스 공유) 헤더가 생성됩니다. 자세한 내용은 Azure Storage 서비스대한 |
x-ms-client-request-id |
선택적. 스토리지 분석 로깅을 사용하도록 설정할 때 분석 로그에 기록되는 1kibibyte(KiB) 문자 제한으로 클라이언트에서 생성된 불투명 값을 제공합니다. 이 헤더를 사용하여 클라이언트 쪽 활동과 서버가 수신하는 요청의 상관 관계를 지정하는 것이 좋습니다. |
x-ms-access-tier |
선택적. Blob에서 설정할 계층을 나타냅니다. 블록 Blob 계층에 유효한 값은 Hot , Cool , Cold 및 Archive .
참고: Cold 계층은 버전 2021-12-02 이상에서 지원됩니다.
Hot , Cool 및 Archive 버전 2018-11-09 이상에서 지원됩니다. 블록 Blob 계층화에 대한 자세한 내용은 핫, 쿨 및 보관 스토리지 계층참조하세요. |
x-ms-expiry-option |
선택적. 버전 2023-08-03 이상. 요청에 대한 만료 날짜 옵션을 지정합니다. 자세한 내용은 ExpiryOption참조하세요. 이 헤더는 계층 구조 네임스페이스를 사용하도록 설정된 계정에 유효합니다. |
x-ms-expiry-time |
선택적. 버전 2023-08-03 이상. Blob이 만료되도록 설정된 시간을 지정합니다. 만료 날짜의 형식은 x-ms-expiry-option 따라 다릅니다. 자세한 내용은 ExpiryOption참조하세요. 이 헤더는 계층 구조 네임스페이스를 사용하도록 설정된 계정에 유효합니다. |
또한 이 작업은 특정 조건이 충족되는 경우에만 조건부 헤더를 사용하여 Blob을 작성하도록 지원합니다. 자세한 내용은 Blob Storage 작업대한 조건부 헤더 지정을 참조하세요.
요청 헤더(고객이 제공한 암호화 키)
고객이 제공한 키를 사용하여 Blob을 암호화하는 요청에 다음 헤더를 지정할 수 있습니다. 고객이 제공한 키(및 해당 헤더 집합)를 사용한 암호화는 선택 사항입니다.
요청 헤더 | 묘사 |
---|---|
x-ms-encryption-key |
필수. Base64로 인코딩된 AES-256 암호화 키입니다. |
x-ms-encryption-key-sha256 |
필수. 암호화 키의 Base64로 인코딩된 SHA256 해시입니다. |
x-ms-encryption-algorithm: AES256 |
필수. 암호화에 사용할 알고리즘을 지정합니다. 이 헤더의 값은 AES256 합니다. |
요청 본문
없음.
샘플 요청
다음 예제에서는 블록 Blob을 만들기 위한 요청을 보여줍니다.
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblockblob HTTP/1.1
Request Headers:
x-ms-version: 2020-04-08
x-ms-date: <date>
Content-Type: text/plain; charset=UTF-8
x-ms-blob-content-disposition: attachment; filename="fname.ext"
x-ms-blob-type: BlockBlob
x-ms-meta-m1: v1
x-ms-meta-m2: v2
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=
Content-Length: 0
응답
응답에는 HTTP 상태 코드와 응답 헤더 집합이 포함됩니다.
상태 코드
작업이 성공하면 상태 코드 201(생성됨)이 반환됩니다.
상태 코드에 대한 자세한 내용은 상태 및 오류 코드참조하세요.
응답 헤더
이 작업에 대한 응답에는 다음 헤더가 포함됩니다. 응답에는 추가 표준 HTTP 헤더도 포함될 수 있습니다. 모든 표준 헤더는 HTTP/1.1 프로토콜 사양준수합니다.
응답 헤더 | 묘사 |
---|---|
ETag |
ETag에는 클라이언트가 If-Match 요청 헤더를 사용하여 조건부 PUT 작업을 수행하는 데 사용할 수 있는 값이 포함되어 있습니다. ETag 값은 따옴표로 묶습니다. |
Last-Modified |
Blob이 마지막으로 수정된 날짜/시간입니다. 날짜 형식은 RFC 1123을 따릅니다. 자세한 내용은 헤더날짜/시간 값을 나타냅니다. Blob에 대한 쓰기 작업(Blob의 메타데이터 또는 속성에 대한 업데이트 포함)은 Blob의 마지막으로 수정된 시간을 변경합니다. |
Content-MD5 |
클라이언트가 메시지 콘텐츠의 무결성을 확인할 수 있도록 블록 Blob에 대해 반환됩니다. 반환된 Content-MD5 값은 Blob Storage에서 계산됩니다. 요청에 Content-MD5 또는 x-ms-blob-content-md5 헤더가 포함되지 않은 경우에도 이 헤더가 반환됩니다. |
x-ms-content-crc64 |
클라이언트가 메시지 콘텐츠의 무결성을 확인할 수 있도록 블록 Blob에 대해 반환됩니다. 반환된 x-ms-content-crc64 값은 Blob Storage에서 계산됩니다. 이 헤더는 항상 반환됩니다. |
x-ms-request-id |
만들어진 요청을 고유하게 식별하며 이를 사용하여 요청 문제를 해결할 수 있습니다. 자세한 내용은 API 작업문제 해결을 참조하세요. |
x-ms-version |
요청을 실행하는 데 사용된 Blob Storage의 버전입니다. |
Date |
서비스에서 생성되는 UTC 날짜/시간 값으로, 응답이 시작된 시간을 나타냅니다. |
Access-Control-Allow-Origin |
요청에 Origin 헤더가 포함되고 CORS가 일치하는 규칙으로 사용하도록 설정된 경우 반환됩니다. 일치하는 항목이 있는 경우 이 헤더는 원본 요청 헤더의 값을 반환합니다. |
Access-Control-Expose-Headers |
요청에 Origin 헤더가 포함되고 CORS가 일치하는 규칙으로 사용하도록 설정된 경우 반환됩니다. 요청의 클라이언트 또는 발급자에게 노출될 응답 헤더 목록을 반환합니다. |
Access-Control-Allow-Credentials |
요청에 Origin 헤더가 포함되어 있고 CORS가 모든 원본을 허용하지 않는 일치 규칙으로 사용하도록 설정된 경우 반환됩니다. 이 헤더는 true . |
x-ms-request-server-encrypted: true/false |
지정된 알고리즘을 사용하여 요청 내용이 성공적으로 암호화되면 이 헤더의 값이 true 설정됩니다. 그렇지 않으면 값이 false 설정됩니다. |
x-ms-encryption-key-sha256 |
클라이언트가 제공된 키를 사용하여 요청 내용이 성공적으로 암호화되도록 요청에서 고객이 제공한 키를 암호화에 사용한 경우 반환됩니다. |
x-ms-encryption-scope |
클라이언트가 암호화 범위를 사용하여 요청 내용이 성공적으로 암호화되도록 요청이 암호화 범위를 사용한 경우 반환됩니다. |
x-ms-version-id: <DateTime> |
Blob을 고유하게 식별하는 불투명 DateTime 값을 반환합니다. 이 헤더의 값은 Blob의 버전을 나타내며, Blob에 액세스하기 위한 후속 요청에 사용될 수 있습니다. |
응답 본문
없음.
샘플 응답
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==
x-ms-content-crc64: 77uWZTolTHU
Date: <date>
ETag: "0x8CB171BA9E94B0B"
Last-Modified: <date>
Access-Control-Allow-Origin: http://contoso.com
Access-Control-Expose-Headers: Content-MD5
Access-Control-Allow-Credentials: True
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-version-id: <DateTime>
권한 부여
Azure Storage에서 데이터 액세스 작업을 호출할 때 권한 부여가 필요합니다. 아래 설명된 대로 Put Blob From URL
작업에 권한을 부여할 수 있습니다.
요청이 x-ms-tags
요청 헤더를 사용하여 태그를 지정하는 경우 호출자는 Blob 태그 설정 작업의 권한 부여 요구 사항을 충족해야 합니다.
중요하다
Microsoft는 관리 ID와 함께 Microsoft Entra ID를 사용하여 Azure Storage에 대한 요청을 승인하는 것이 좋습니다. Microsoft Entra ID는 공유 키 권한 부여에 비해 뛰어난 보안 및 사용 편의성을 제공합니다.
-
microsoft Entra ID(권장)
-
SAS(공유 액세스 서명)
-
공유 키
Azure Storage는 Microsoft Entra ID를 사용하여 Blob 데이터에 대한 요청을 승인하도록 지원합니다. Microsoft Entra ID를 사용하면 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 보안 주체에 권한을 부여할 수 있습니다. 보안 주체는 사용자, 그룹, 애플리케이션 서비스 주체 또는 Azure 관리 ID일 수 있습니다. 보안 주체는 OAuth 2.0 토큰을 반환하기 위해 Microsoft Entra ID에 의해 인증됩니다. 그런 다음 토큰을 사용하여 Blob 서비스에 대한 요청에 권한을 부여할 수 있습니다.
Microsoft Entra ID를 사용한 권한 부여에 대한 자세한 내용은 Microsoft Entra ID사용하여 Blob에 대한 액세스 권한 부여를 참조하세요.
권한을
아래에는 Microsoft Entra 사용자, 그룹, 관리 ID 또는 서비스 주체가 Put Blob From URL
작업을 호출하는 데 필요한 RBAC 작업과 이 작업을 포함하는 최소 권한의 기본 제공 Azure RBAC 역할이 나와 있습니다.
- Azure RBAC 작업 :
- 새 블록 Blob 만들기: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
- 기존 블록 Blob을 새로 만들거나 덮어씁니다. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- 최소 권한 기본 제공 역할:Storage Blob 데이터 기여자
Azure RBAC를 사용하여 역할을 할당하는 방법에 대한 자세한 내용은 Blob 데이터액세스하기 위한 Azure 역할 할당을 참조하세요.
발언
Put Blob From URL
작업은 버전 2020-04-08을 기준으로 지원됩니다.
버전 2020-10-02 이상에서는 복사 작업의 원본에 대해 Microsoft Entra 권한 부여가 지원됩니다.
원본 Blob은 블록 Blob, 추가 Blob 또는 페이지 Blob을 비롯한 모든 형식일 수 있습니다. 그러나 대상 Blob은 블록 Blob이어야 합니다.
Put Blob From URL
작업은 항상 전체 원본 Blob을 복사합니다. 바이트 범위 또는 블록 집합 복사는 지원되지 않습니다. 부분 업데이트를 수행하려면 URL차단
블록 Blob을 원본 개체로 사용하는 경우 커밋된 모든 Blob 콘텐츠가 복사됩니다. 그러나 블록 목록은 유지되지 않으며 커밋되지 않은 블록은 복사되지 않습니다. 대상 Blob의 콘텐츠는 원본의 내용과 동일하지만 커밋된 블록 목록은 유지되지 않습니다.
Blob 속성 및 메타데이터 배치
복사 원본에서 블록 Blob을 만들 때 표준 Blob 속성은 기본적으로 원본 Blob에서 복사됩니다. 애플리케이션 메타데이터가 요청에 지정된 경우 원본 Blob 메타데이터를 복사하지 않고 저장됩니다. HTTP 콘텐츠 헤더를 명시적으로 설정하려면 요청에서 해당 헤더를 지정할 수 있습니다.
Content-Type
Content-Encoding
Content-Length
Cache-Control
Content-Disposition
대상 Blob의 크기는 항상 원본 Blob의 크기와 일치합니다.
Content-Length
헤더는 요청 본문이 없기 때문에 Put Blob From URL
요청에서 0이어야 하며 대상 Blob의 콘텐츠 길이 속성은 원본 크기에서 유추됩니다.
URL에서 Blob 배치 사용자 지정 속성
Put Blob From Url
표준 HTTP 헤더와 연결된 사용자 지정 속성을 설정하는 Put Blob
동일한 의미 체계를 따릅니다. 자세한 내용은 Blob 사용자 지정 속성 참조하세요.
Blob 인덱스 태그
대상 Blob에 대한 태그가 x-ms-tags
헤더에 제공된 경우 쿼리 문자열로 인코딩되어야 합니다. 태그 키와 값은 Set Blob Tags
지정된 이름 및 길이 요구 사항을 준수해야 합니다. 또한 x-ms-tags
헤더에는 최대 2KiB의 태그가 포함될 수 있습니다. 더 많은 태그가 필요한 경우 Set Blob Tags
작업을 사용합니다.
태그가 x-ms-tags
헤더에 제공되지 않으면 원본 Blob에서 복사되지 않습니다.
암호화 범위 및 고객이 제공한 키
Put Blob From URL
API는 각각 x-ms-encryption-scope
및 x-ms-encryption-key
헤더를 사용하여 암호화 범위와 고객이 제공한 키를 모두 지원합니다.
x-ms-copy-source
헤더가 요청 URI의 대상 Blob과 동일한 원본 Blob을 참조하는 경우 Put Blob From URL
작업은 Blob의 동기적인 현재 위치 다시 쓰기를 수행합니다. 이렇게 하면 Blob을 다시 작성하여 다른 암호화 키 또는 암호화 범위를 사용할 수 있습니다.
과금
가격 책정 요청은 Blob Storage REST API를 통해 직접 Blob Storage API를 사용하는 클라이언트 또는 Azure Storage 클라이언트 라이브러리에서 비롯할 수 있습니다. 이러한 요청은 트랜잭션당 요금이 발생합니다. 트랜잭션 유형은 계정에 청구되는 방식에 영향을 줍니다. 예를 들어 읽기 트랜잭션은 쓰기 트랜잭션과 다른 청구 범주에 발생합니다. 다음 표에서는 스토리지 계정 유형에 따라 Put Blob From URL
요청에 대한 청구 범주를 보여 줍니다.
수술 | 스토리지 계정 유형 | 청구 범주 |
---|---|---|
Url에서 Blob 배치(대상 계정1) | 프리미엄 블록 Blob 표준 범용 v2 표준 범용 v1 |
쓰기 작업 |
URL에서 Blob 배치(원본 계정2) | 프리미엄 블록 Blob 표준 범용 v2 표준 범용 v1 |
읽기 작업 |
1대상 계정은 쓰기를 시작하는 하나의 트랜잭션에 대해 요금이 청구됩니다.
2원본 계정은 원본 개체에 대한 각 읽기 요청에 대해 하나의 트랜잭션을 발생합니다.
또한 원본 및 대상 계정이 다른 지역(예: 미국 북부 및 미국 남부)에 있는 경우 요청을 전송하는 데 사용되는 대역폭은 송신으로 원본 스토리지 계정에 청구됩니다. 동일한 지역 내의 계정 간 송신은 무료입니다.
마지막으로 동일한 스토리지 계정 내에서 다른 이름으로 새 Blob을 만들면 추가 스토리지 리소스가 사용되므로 해당 추가 리소스에 대한 스토리지 계정의 용량 사용량에 대한 요금이 청구됩니다.
지정된 청구 범주의 가격 책정에 대한 자세한 내용은 Azure Blob Storage 가격 책정
참고 항목
Azure Storage상태 및 Blob 서비스 오류 코드오류 코드에 대한 요청 권한 부여Blob Service 작업에 대한 제한 시간 설정