Blob Storage returns content with valid "If-Modified-Since" header. Is this correct?

Question

I've encountered a weird behavior, while working with the blob storage (OpenRead). That's how the request looks like:

GET /devstoreaccount1/test/test?comp=blocklist&blocklisttype=Committed&timeout=90 HTTP/1.1
x-ms-version: 2009-09-19
If-Modified-Since: Sun, 08 Aug 2010 16:37:39 GMT
x-ms-date: Sun, 08 Aug 2010 16:37:40 GMT
Authorization: SharedKey devstoreaccount1:6WlRw9J5Qx2YFVuHeavu/gcGw+Qj10NbOimdBUlFeC8=
Host: 127.0.0.1:10000

The response is:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/xml
Last-Modified: Sun, 08 Aug 2010 16:37:39 GMT
ETag: 0x8CD052F26689D60
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: b11b848e-db41-4566-85db-f929a18673ac
x-ms-version: 2009-09-19
x-ms-blob-content-length: 16
Date: Sun, 08 Aug 2010 16:37:40 GMT

The response should be 304 (not modified) without any content as per RFC-1945 , should it not?

Note, that the server itself returns Last-modified that seems to violate If-modified-since condition.

 

---

http://abdullin.com

Answer 1

Hi Rinat,

I looked up the documentation of "Get Block List" here: http://msdn.microsoft.com/en-us/library/dd179400.aspx and it mentions that this operation supports conditional headers however if you read the documentation for conditional headers here: http://msdn.microsoft.com/en-us/library/dd179371.aspx , this particular operation is missing from the list of blob operations where conditional headers are supported. Could it be possible that this operation in fact does not support conditional headers at all?

Thanks

Gaurav Mantri

Cerebrata Software

http://www.cerebrata.com

Answer 2

Hi Guarav,

Hm.... after double-checking tests, RFC and documentation I see that conditional request headers still work properly for If-Match and if-unmodified scenarios, although they should probably be ignored according to the documentation (which is quite confusing for GetBlockList )

However .NET StorageClient description of CloudBlob.OpenRead(options) does not say anything about ignoring some of the conditional headers and complying to the other.

I'm left quite confused. Any clarification from the MS team?

Answer 3

Update: I've assembled a blog post on the subject .

Update2 : if this could help, current source code for some tests is available in Lokad.CQRS (current changeset link )

---

http://abdullin.com

Answer 4

Hi Rinat,

 We do not support conditional headers on GetBlockList. We will correct our documentation for GetBlockList and sorry for any inconvenience this has caused. Until then,  please refer to the documentation at http://msdn.microsoft.com/en-us/library/dd179371.aspx for list of operations that support conditional headers. 

Thanks,

Jai

Answer 5

Thank you for the update!

What about GetBlob operation? It is listed in the list, but still does not behave accordingly to the conditional header specs:

When we have missing item, then following request:

GET /devstoreaccount1/tc-af5d8d3b-3e65-42fc-9997-43b4eb2ddfd0/62a53020-d6e2-4b2b-b774-e0ecc7f71b5e?timeout=90 HTTP/1.1
x-ms-version: 2009-09-19
x-ms-range: bytes=0-214748364799
If-Match: mismatch
x-ms-date: Wed, 11 Aug 2010 18:29:45 GMT
Authorization: SharedKey devstoreaccount1:Cl439uytdlS9uDSfQIl6TSAGLJbgK6rnoViLwg7Caxk=
Host: 127.0.0.1:10000

Returns:

HTTP/1.1 412 The condition specified using HTTP conditional header(s) is not met.
Content-Length: 252
Content-Type: application/xml
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: bf943a1a-b1d0-4274-b12c-a7fc888f93ef
x-ms-version: 2009-09-19
Date: Wed, 11 Aug 2010 18:29:44 GMT

While it should return Not Found . Get blob with missing container or  put blob with missing container - same story. And these are just the methods we've unit tested.

 

Could you, please, tell if I'm reading the specs and documentation wrong, or this is something to be fixed?

Thanks in advance!

---

http://abdullin.com

Answer 6

Hi Rinat,

As covered in the other thread, providing an ill-formatted tag leads to 412. We will update the document.

Thanks,

jai