Umieść blok z adresu URL

Operacja tworzy nowy blok do zatwierdzona jako część obiektu blob, w którym Put Block From URL zawartość jest odczytywana z adresu URL. Ten interfejs API jest dostępny od wersji 2018-03-28 .

Żądanie

Żądanie Put Block From URL może zostać skonstruowane w następujący sposób. Protokół HTTPS jest zalecany. Zastąp myaccount nazwą swojego konta magazynu:

PUT Method Request URI	Wersja PROTOKOŁU HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id	HTTP/1.1

Emulowany Storage URI usługi

Podczas tworzenia żądania względem emulowanej usługi magazynu określ nazwę hosta emulatora i port Blob service jako , a następnie 127.0.0.1:10000 nazwę emulowanej konta magazynu:

PUT Method Request URI	Wersja PROTOKOŁU HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id	HTTP/1.1

Aby uzyskać więcej informacji, zobacz Using the Azure Storage Emulator for Development and Testing (Używanie usługi Azure Storage Emulator for Development and Testing).

Parametry identyfikatora URI

Parametr	Opis
blockid	Wymagane. Prawidłowa wartość ciągu Base64, która identyfikuje blok. Przed kodowaniem ciąg musi być mniejszy lub równy 64 bajtom. Dla danego obiektu blob długość wartości określonej dla parametru musi być taka sama dla blockid każdego bloku. Należy pamiętać, że ciąg Base64 musi być zakodowany w adresie URL.
timeout	Opcjonalny. Parametr timeout jest wyrażony w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Service.

Nagłówki żądań

W poniższej tabeli opisano wymagane i opcjonalne nagłówki żądań.

Nagłówek żądania	Opis
Authorization	Wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Authorize requests to Azure Storage (Autoryzowanie żądań do usługi Azure Storage).
Date lub x-ms-date	Wymagane. Określa dla żądania godzinę w formacie uniwersalnego czasu koordynowanego (UTC). Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-version	Wymagane dla wszystkich autoryzowanych żądań. Określa wersję operacji do użycia dla tego żądania. Aby uzyskać więcej informacji, zobacz Versioning for the Azure Storage Services (Wersjeusług Azure Storage Services). W przypadku pliku Put Block From URL (Umieść blok z adresu URL) należy wprowadzić wersję 2018-03-28 lub nowszą.
Content-Length	Wymagane. Określa liczbę bajtów przesyłanych w treści żądania. Wartość tego nagłówka musi być ustawiona na zero. Gdy długość nie jest równa zero, operacja nie powiedzie się z kodem stanu 400 (Złe żądanie).
x-ms-copy-source:name	Wymagane. Określa adres URL źródłowego obiektu blob. Wartość może być adresem URL o długości do 2 KiB, który określa obiekt blob. Wartość powinna być zakodowana w adresie URL, tak jak byłaby wyświetlana w polu URI żądania. Źródłowy obiekt blob musi być publiczny lub musi być autoryzowany za pośrednictwem sygnatury dostępu współdzielowego. Jeśli źródłowy obiekt blob jest publiczny, do wykonania operacji nie jest wymagana autoryzacja. Oto kilka przykładów adresów URL obiektów źródłowych: - 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>	Opcjonalny. Określa schemat autoryzacji i podpis dla źródła kopii. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage. Tylko bearer schematu jest obsługiwany dla Azure Active Directory. Ten nagłówek jest obsługiwany w wersjach 2020-10-02 i nowszych.
x-ms-source-range	Opcjonalny. Przekazywanie tylko bajtów obiektu blob w źródłowym adresie URL w określonym zakresie. Jeśli nie zostanie to określone, cała zawartość źródłowego obiektu blob zostanie przesłana jako pojedynczy blok. Aby uzyskać więcej informacji, zobacz Specifying the Range Header for Blob Service Operations (Określanie nagłówka zakresu dla operacji usługi Blob Service).
x-ms-source-content-md5	Opcjonalny. Skrót MD5 zawartości bloku z URI. Ten skrót służy do weryfikowania integralności bloku podczas transportu danych z URI. Gdy ten nagłówek jest określony, usługa magazynu porównuje skrót zawartości, która dotarła ze źródła kopii, z tą wartością nagłówka. Należy pamiętać, że ten skrót md5 nie jest przechowywany razem z obiektem blob. Jeśli te dwa skróty nie są zgodne, operacja nie powiedzie się z kodem błędu 400 (Złe żądanie).
x-ms-source-content-crc64	Opcjonalny. Skrót CRC64 zawartości bloku z URI. Ten skrót służy do weryfikowania integralności bloku podczas transportu danych z URI. Gdy ten nagłówek jest określony, usługa magazynu porównuje skrót zawartości, która dotarła ze źródła kopii, z tą wartością nagłówka. Należy pamiętać, że ten skrót CRC64 nie jest przechowywany z obiektem blob. Jeśli te dwa skróty nie są zgodne, operacja nie powiedzie się z kodem błędu 400 (Złe żądanie). Jeśli istnieją nagłówki i , żądanie nie powiedzie się z x-ms-source-content-md5 x-ms-source-content-crc64 400 (Złym żądaniem). Ten nagłówek jest obsługiwany w wersjach 2019-02-02 lub nowszych.
x-ms-encryption-scope	Opcjonalny. Wskazuje zakres szyfrowania używany do szyfrowania zawartości źródłowej. Ten nagłówek jest obsługiwany w wersjach 2019-02-02 lub nowszych.
x-ms-lease-id:<ID>	Wymagane, jeśli obiekt blob ma aktywną dzierżawę. Aby wykonać tę operację na obiekcie blob z aktywną dzierżawą, określ prawidłowy identyfikator dzierżawy dla tego nagłówka.
x-ms-client-request-id	Opcjonalny. Zapewnia wygenerowaną przez klienta nieprzezroczystą wartość z limitem znaków 1 KiB, który jest rejestrowany w dziennikach analizy po włączeniu rejestrowania analizy magazynu. Używanie tego nagłówka jest wysoce zalecane do korelowania działań po stronie klienta z żądaniami odebranymi przez serwer. Aby uzyskać więcej informacji, zobacz About Storage Analytics Logging and Azure Logging: Using Logs to Track Storage Requests (Informacje o rejestrowaniu usługi Azure Analytics i rejestrowaniu na platformie Azure: używanie dzienników do śledzenia Storage żądań).

Nagłówki żądań (klucze szyfrowania dostarczane przez klienta)

Począwszy od wersji 2019-02-02, w żądaniu można określić następujące nagłówki w celu zaszyfrowania obiektu blob przy użyciu klucza dostarczonego przez klienta. Szyfrowanie za pomocą klucza dostarczonego przez klienta (i odpowiedniego zestawu nagłówków) jest opcjonalne.

Nagłówek żądania	Opis
x-ms-encryption-key	Wymagane. Klucz szyfrowania AES-256 zakodowany w formacie Base64.
x-ms-encryption-key-sha256	Wymagane. Skrót SHA256 klucza szyfrowania zakodowany w formacie Base64.
x-ms-encryption-algorithm: AES256	Wymagane. Określa algorytm używany do szyfrowania. Wartość tego nagłówka musi być AES256 .

Treść żądania

Brak treści żądania.

Przykładowe żądanie

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

Reakcja

Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.

Kod stanu

Pomyślna operacja zwraca kod stanu 201 (Utworzono).

Aby uzyskać informacje o kodach stanu, zobacz Kody stanu i błędów.

Nagłówki odpowiedzi

Odpowiedź na tę operację zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1.

Nagłówek odpowiedzi	Opis
Content-MD5	Ten nagłówek jest zwracany, dzięki czemu klient może sprawdzić integralność zawartości wiadomości. Wartość tego nagłówka jest obliczana przez Blob service; Nie musi to być ta sama wartość określona w nagłówkach żądania. W przypadku wersji 2019-02-02 lub nowszej ten nagłówek jest zwracany tylko wtedy, gdy żądanie ma ten nagłówek.
x-ms-content-crc64	W przypadku wersji 2019-02-02 lub nowszej ten nagłówek jest zwracany, aby klient może sprawdzić integralność zawartości wiadomości. Wartość tego nagłówka jest obliczana przez Blob service; Nie musi to być ta sama wartość określona w nagłówkach żądania. Ten nagłówek jest zwracany, x-ms-source-content-md5 gdy nagłówek nie jest obecny w żądaniu.
x-ms-request-id	Ten nagłówek unikatowo identyfikuje żądanie, które zostało wykonane, i może służyć do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Troubleshooting API Operations (Rozwiązywanie problemów z operacjami interfejsu API).
x-ms-version	Wskazuje wersję pliku Blob service do wykonania żądania.
Date	Wartość daty/czasu UTC wygenerowana przez usługę, która wskazuje czas, o której została zainicjowana odpowiedź.
x-ms-request-server-encrypted: true/false	Wersja 2015-12-11 lub nowsza. Wartość tego nagłówka jest ustawiona na , jeśli zawartość bloku została pomyślnie zaszyfrowana przy użyciu true określonego algorytmu i false w przeciwnym razie.
x-ms-encryption-key-sha256	Wersja 2019-02-02 lub nowsza. Ten nagłówek jest zwracany, jeśli żądanie używa klucza dostarczonego przez klienta do szyfrowania, dzięki czemu klient może upewnić się, że zawartość żądania została pomyślnie zaszyfrowana przy użyciu podanego klucza.
x-ms-encryption-scope	Wersja 2019-02-02 lub nowsza. Ten nagłówek jest zwracany, jeśli żądanie używa zakresu szyfrowania, dzięki czemu klient może upewnić się, że zawartość żądania została pomyślnie zaszyfrowana przy użyciu zakresu szyfrowania.
x-ms-client-request-id	Ten nagłówek może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi odpowiedziami. Wartość tego nagłówka jest równa wartości nagłówka, jeśli jest obecny w żądaniu, a wartość jest co najwyżej 1024 widocznych znaków x-ms-client-request-id ASCII. Jeśli nagłówek x-ms-client-request-id nie jest obecny w żądaniu, ten nagłówek nie będzie obecny w odpowiedzi.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  

Autoryzacja

Ta operacja może zostać wywołana przez właściciela konta i przez każdego, kto ma sygnaturę dostępu współdzielonych z uprawnieniami do zapisu do tego obiektu blob lub jego kontenera.

Uwagi

Put Block From URL program przekaże blok do przyszłego włączenia do blokowego obiektu blob. Blokowy obiekt blob może zawierać maksymalnie 50 000 bloków. Każdy blok może mieć inny rozmiar. Maksymalny rozmiar bloku przekazanego za Put Block From URL pomocą pliku to 100 MiB. Aby przekazać większe bloki (do 4000 MiB), zobacz Put Block.

W wersji 2020-10-02 i nowszej Azure Active Directory autoryzacja jest obsługiwana dla źródła operacji kopiowania.

Obiekt blob może mieć maksymalnie 100 000 niezatwierdzony bloków w danym momencie. Jeśli to maksimum zostanie przekroczone, usługa zwraca kod stanu 409 (RequestEntityTooLargeBlockCountExceedsLimit).

W poniższej tabeli opisano maksymalne rozmiary bloków i obiektów blob dozwolone przez wersję usługi.

Wersja usługi	Maksymalny rozmiar bloku (za pośrednictwem bloku put z adresu URL)	Maksymalny rozmiar obiektu blob (za pośrednictwem listy bloków put)	Maksymalny rozmiar obiektu blob za pośrednictwem pojedynczej operacji zapisu (za pośrednictwem operacji Put Blob from URL (Umieść obiekt blob z adresu URL)
Wersja 2020-04-08 lub nowsza	4000 MiB	Około 190,7 TiB (4000 MiB x 50 000 bloków)	5000 MiB (wersja zapoznawcza)
Wersje wcześniejsze niż 2020-04-08	100 MiB	Około 4,75 TiB (100 MiB x 50 000 bloków)	256 MiB

Po przesłaniu zestawu bloków można utworzyć lub zaktualizować obiekt blob na serwerze z tego zestawu, wywołując operację Umieść listę zablokowanych. Każdy blok w zestawie jest identyfikowany przez identyfikator bloku, który jest unikatowy w obrębie tego obiektu blob. Zakres identyfikatorów bloków jest ograniczony do określonego obiektu blob, więc różne obiekty blob mogą mieć bloki o tych samych identyfikatorach.

Jeśli wywołasz obiekt blob, który jeszcze nie istnieje, zostanie utworzony nowy blokowy obiekt blob o długości Put Block From URL zawartości 0. Ten obiekt blob jest wyliczany przez List Blobs operację, jeśli include=uncommittedblobs określono opcję . Przekazany blok lub bloki nie zostaną zatwierdzone, dopóki nie wywołasz Put Block List wywołania dla nowego obiektu blob. Obiekt blob utworzony w ten sposób jest utrzymywany na serwerze przez tydzień. Jeśli w tym czasie nie dodano więcej bloków lub zatwierdzone bloki do obiektu blob, obiekt blob jest odśmiecany.

Blok, który został pomyślnie przekazany za pomocą operacji , nie staje się częścią obiektu blob, dopóki nie Put Block From URL zostanie on zatwierdzone za pomocą . Put Block List Zanim zostanie wywołana w celu zatwierdzenia nowego lub zaktualizowanego obiektu blob, wszystkie wywołania w celu uzyskania obiektu blob zwracają zawartość obiektu blob bez dołączania Put Block List niezatwierdzony blok.

Jeśli przekażemy blok o tym samym identyfikatorze bloku co inny blok, który nie został jeszcze zatwierdzone, ostatni przekazany blok z tym identyfikatorem zostanie zatwierdzone podczas następnej pomyślnej Put Block List operacji.

Po Put Block List wywołaniu wszystkie niezatwierdzone bloki określone na liście bloków są zatwierdzone jako część nowego obiektu blob. Wszystkie niezatwierdzone bloki, które nie zostały określone na liście bloków dla obiektu blob, zostaną odśmiecane i usunięte z Blob service. Wszelkie niezatwierdzone bloki również zostaną odśmiecane, jeśli w ciągu tygodnia od ostatniej pomyślnej operacji nie będzie żadnych pomyślnych wywołań do lub do tego samego Put Block From URL Put Block List obiektu Put Block From URL blob. Jeśli obiekt blob Put zostanie wywołany w obiekcie blob, wszelkie niezatwierdzone bloki zostaną odśmiecane.

Jeśli obiekt blob ma aktywną dzierżawę, klient musi określić prawidłowy identyfikator dzierżawy w żądaniu, aby zapisać blok w obiekcie blob. Jeśli klient nie określi identyfikatora dzierżawy lub określi nieprawidłowy identyfikator dzierżawy, Blob service zwraca kod stanu 412 (Niepowodzenie warunku wstępnego). Jeśli klient określa identyfikator dzierżawy, ale obiekt blob nie ma aktywnej dzierżawy, Blob service zwraca również kod stanu 412 (Niepowodzenie warunku wstępnego).

Dla danego obiektu blob wszystkie identyfikatory bloków muszą mieć taką samą długość. Jeśli blok zostanie przekazany z identyfikatorem bloku o innej długości niż identyfikatory bloków dla istniejących niezatwierdzony bloków, usługa zwraca kod odpowiedzi błędu 400 (Złe żądanie).

Wywołanie Put Block From URL nie aktualizuje czasu ostatniej modyfikacji istniejącego obiektu blob.

Wywołanie Put Block From URL metody dla stronicowego obiektu blob zwraca błąd.

Wywołanie Put Block From URL dla zarchiwizowany obiekt blob zwróci błąd i Hot / Cool obiekt blob nie zmienia warstwy obiektu blob.

Zobacz też

• Autoryzowanie żądań do usługi Azure Storage
• Kody stanu i błędów
• Kody błędów usługi Blob Service
• Ustawianie limitów czasu dla operacji usługi Blob Service