put block fails when BlockId is "AAAA+A=="

Question

I cannot seem to be able to put a block when I base64 encode 248 in big endian therefore my blockId is "AAAA+A==". Do I need to escape it? If so how would the url look.

Thanks

Answer 1

what is the specific exception/error you are recieving when you attempt it?

Answer 2

what is the specific exception/error you are recieving when you attempt it?

I don't know what the string was, but it was code 400, I also want to say that this failed after successfully putting up blocks 1->247, and then I tried starting new put blocks on new blobs with the blockId of AAAA+A== are plus signs allowed in block ids? I haven't been able to commit any block with that id so far.

Thanks

Answer 3

The specific exception would help tremendously. I've seen the plus signs succesfully passed to queues without issue. So I doubt that is the problem. Especially given that its simply the base64 encoded version of 248.

Take a look at the following link and see if any of the items listed there look familiar: http://msdn.microsoft.com/en-us/library/dd179439.aspx

The 400 code could mean one of three things, and while Block ID is one of them. I also snagged this from the Azure SDK on MSDN...

Required. A valid Base64 string value that identifies the block. Prior to encoding, the string must be less than or equal to 64 bytes in size.

For a given blob, the length of the value specified for the blockid parameter must be the same size for each block.

The piece that concerns me is the second line. If the base 64 value for 248 is longer then any other, its possible that's your culprit. I would what would happen if your block IDs were all 6 digits before encoding. So instead of 248... you used 000001-000248.

Answer 4

or a given blob, the length of the value specified for the blockid parameter must be the same size for each block.The piece that concerns me is the second line. If the base 64 value for 248 is longer then any other, its possible that's your culprit. I would what would happen if your block IDs were all 6 digits before encoding. So instead of 248... you used 000001-000248.

I will have access to my dev machine again in ~6 hours, but the above shouldn't be the case I was always base encoding 4 byte unsigned ints. Also it happened when that block id represented the first block in other put block requests, therefore there was no other block to have a different size with. I can tell you it isn't an invalid block or blob content due to the fact I took a datastream I had commited successfully and it failed when using this block id, and I am not doing a put block list operation. Does that block Id work for anyone else?

Answer 5

so it seems '+' needs to be escaped
below is the trace

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib2.py", line 124, in urlopen
    return _opener.open(url, data)
  File "/usr/lib/python2.5/urllib2.py", line 387, in open
    response = meth(req, response)
  File "/usr/lib/python2.5/urllib2.py", line 498, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.5/urllib2.py", line 425, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Value for one of the query parameters specified in the request URI is invalid.

Answer 6

Well it does look like + needs to be escape. Anyways it was easily fixed urllib2.quote(block_id, safe=''). I do not specify that = is safe even though I know it is.

Thanks for the help