Skip to content


Subversion checkout URL

You can clone with
Download ZIP


put block list #31

gabpaquin opened this Issue · 9 comments

3 participants


Hi Johnny,

It took while to find this one (I was not looking in the good direction) but I just realized that the headers for put blob and put block list are slightly different regarding the content type.

Put block list :, it is mention that to set the content type we need to set the x-ms-blob-content-type in the header.

This is different from put blob ( where we need to set the Content type through the Content-Type properties in the header.

So I had to set the default_headers to the following in order to work in the put_block_list:

         default_headers = {"Content-Type" => content_type, "x-ms-blob-content-type" =>        content_type, :x_ms_version => "2011-08-18"}

However I still don't understand why if I go through the put_blob method i am getting a 403 rest:client error (even though my content is less than 4 mb). Any hint on this one?

Thanks a lot your gem is quite useful!



I think @smarx is the right person to answer here as he is the one that put that together. I don't remember exactly how it worked.


FYI, it's safe to just always use x-ms-blob-content-type, since that header works for Put Blob too.

As to why you're getting a 403 when calling put_blob, I have no idea. I haven't touched put_blob. Are you saying that you get that error using an unmodified version of this librar? What is the body of the 403 response?


Ok thanks a lot for your input I really appreciate.

so regarding x-ms-blob-content-type what is the best approach? Should we put it into the default_headers like suggested into my first comment?

Then the 403 with put_blob, it is with an unmodified version of this library. If it is the payload is a simple string I don't have any problem. However if the payload is more complex like then I am getting an error. Any ideas, I am thinking that is probably related to the Authentification signature, but I can't tell how it is affected. Any thoughts?


I would say that x-ms-blob-content-type should go in the default_headers list, and Content-Type should not.

As to your put_blob error, perhaps you can share the exact code you're using? I wouldn't expect passing'/path/to/file') to work, but'/path/to/file').read should. (Really, we're now talking about two different issues. Perhaps this put_blob issue should be logged separately with sample code.)


Ok thanks for the quick feedback!

During my test, the only way I can get it to work was if there was both x-ms-blob-content-type and Content-Type where in the default_headers. Otherwise I was getting a 403 error. Here is the exact code:"/Users/gabriel/code/npathway/r8_image/2005_May_second/p13a.png")
my_container = WAZ::Blobs::Container::find("images")

Sorry about the confusion regarding the put_blob method, I will open a different issues with the exact code.



Perhaps a Content-Type header with the value application/xml would be the most accurate, since the actual body of the Put Block call is XML. I notice that the documentation uses a value of text/plain; charset=UTF-8 in the example request, but application/xml seems more correct to me.

My guess is that leaving out Content-Type entirely is causing a signing error, and the simplest thing to do is have one there. But what wouldn't make sense to me is to have something like Content-Type: image/jpeg on a call to Put Block, just because the blob itself is going to be a jpeg.

So I would suggest Content-Type: application/xml and x-ms-blob-content-type: <desired type of the blob>. Note that I haven't tested this.


I think also having Content-Type to application/xml would make more sense. I ran couple of tests (not extensive though) but If I have the following:

      def put_block_list(path, blockids, content_type = "application/octet-stream", metadata = {})        
        default_headers = {"Content-Type" => "application/xml", "x-ms-blob-content-type" => content_type, :x_ms_version => "2011-08-18"}
        execute :put, path, { :comp => 'blocklist' }, metadata.merge(default_headers), '<?xml version="1.0" encoding="utf-8"?><BlockList>' + {|id| "<Latest>#{id.rstrip}</Latest>"}.join + '</BlockList>'

It seems to be working really well. Could we use that approach?


That looks great to me. Would you be willing to submit a pull request and let @johnnyhalife merge it in?


Hey guys, I've just published v1.3.5 on rubygems (and merged on master). I'm assuming that this closes this issue, however if this also closes #32 please close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.