2016-05-04 13 views
0

Der azure BLOB-Speicher scheint die Inhaltslänge falsch festzulegen, wenn Bytebereichsanforderungen ausgeführt werden. Frühere Versionen unterstützen keine Open-End-Anfragen, daher dachte ich, dass mein Problem gelöst wäre (2015-04-05), wenn ich auf die neueste Version umstelle.Azure Blob Store Inhalt-Länge

Hier habe ich eine GET Anfrage für eine Datei in einem azure Blob durchgeführt und die Header ausgedruckt. Ich erwarte, dass die Content-Length die restlichen 255 Bytes sein, sondern ich die gesamte Dateigröße (15601108255)

(server-1)➜ server-1 git:(faster_calls) ✗ curl -I http://ga4ghstore.blob.core.windows.net/testing/HG00096.mapped.ILLUMINA.bwa.GBR.low_coverage.20120522.bam --header "x-ms-version: 2015-04-05" --range 15601108000- HTTP/1.1 200 OK Content-Length: 15601108255 Content-Type: application/octet-stream Content-MD5: M26lWRO8Jhtyh1vSWXUwRg== Last-Modified: Tue, 26 Apr 2016 18:30:11 GMT Accept-Ranges: bytes ETag: "0x8D36E00CD845EC7" Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 x-ms-request-id: 2bf052dc-0001-013d-256d-a5a7a7000000 x-ms-version: 2015-04-05 x-ms-write-protection: false x-ms-lease-status: unlocked x-ms-lease-state: available x-ms-blob-type: BlockBlob Date: Tue, 03 May 2016 18:55:49 GMT

Die Bereichsanforderung erscheint richtig gehandhabt werden, finden, wie in der zurück Nutzlast von Die erwartete Größe vergleicht jedoch die Header mit dem, was von Amazon für die gleiche Datei zurückgegeben wird. Der Header "content-length" ist der erwartete "255".

(server-1)➜ server-1 git:(faster_calls) ✗ curl -I --range 15601108000- http://s3.amazonaws.com/1000genomes/phase3/data/HG00096/alignment/HG00096.mapped.ILLUMINA.bwa.GBR.low_coverage.20120522.bam
HTTP/1.1 206 Partial Content x-amz-id-2: w6IO4ezWj2BBTkHA09D9gNRZgkmAQJ8khqc6O9t+Xr+xHmZKvwVTNd0vLCpaVcKoVl/2jZUskug= x-amz-request-id: CE8F86CD94173F51 Date: Tue, 03 May 2016 18:59:22 GMT x-amz-meta-s3cmd-attrs: uid:1000/gname:ubuntu/uname:ubuntu/gid:1000/mode:33204/mtime:1431500614/atime:1431500346/ctime:1431500614 Last-Modified: Wed, 13 May 2015 06:57:53 GMT ETag: "efd6d57b0f27974f6845f4e67a99c1a6-117" Accept-Ranges: bytes Content-Range: bytes 15601108000-15601108254/15601108255 Content-Type: application/gzip; charset=binary Content-Length: 255 Server: AmazonS3

Antwort

0

Ich habe gerade versucht, den gleichen Befehl auf meinem Rechner mit Curl und wenn ich es richtig verstehe, wenn Sie cUrl Befehl mit -I Option auszuführen sind Sie im Wesentlichen eine HEAD Anfrage anstelle einer GET Anfrage machen. Im Wesentlichen macht Ihr Befehl Get Blob Properties REST API-Aufruf, der die Daten nicht zurückgibt.

Also die Antwort ist im Falle von Azure korrekt, weil Content-Length Antwort-Header Ihnen die Größe des Blobs sagen sollte. Wenn Sie die zurückgegebene Größe sehen möchten, müssen Sie die cUrl-Anfrage mit dem Parameter -G (Get) durchführen. und dann werden Sie sehen, dass nur 255 Bytes zurückgegeben werden.

+0

Danke Gaurav! Das hilft! Es scheint, dass Amazon und Microsoft die HEAD-Anfrage anders implementieren. Ich habe curl-vG gefunden und die 206 mit der richtigen Content-Length gefunden. – david4096

+0

Trotzdem glaube ich, dass dies ein Fehler ist: "Die Metainformationen, die in den HTTP - Headern als Antwort auf eine HEAD - Anfrage enthalten sind, SOLLTEN identisch mit den Informationen sein, die als Antwort auf eine GET - Anfrage gesendet werden." (Http://www.w3.org /Protocols/rfc2616/rfc2616-sec9.html) – david4096