Queue messages should be base 64 encoded

[guangyang]

No description provided.

[guangyang]

  def self.message_to_xml(message_text)
    builder = Nokogiri::XML::Builder.new do |xml|
      xml.QueueMessage { xml.MessageText message_text }
    end
    builder.to_xml
  end

[guangyang]

Do you mean base-64 encoded?

[guangyang]

Naturally, yes. Typo. Corrected.

[guangyang]

I don't understand the point of this issue. The user can put any string they want in the message body. If the user wants base-64, then they can do that.

Perhaps the root issue that Nokigiri is not correctly XML escaping arbitrary strings, so if a user uploads "<FOO!" it fails? But the fix for that is different (as @christav can comment to related for his fix for Azure/azure-sdk-for-java#111)

Or is there a different issue?

[guangyang]

The reason is: other SDKs (.net) seem to do this. And so, if we dont do it by default, the user wont be able to read the queue message from other places.

[guangyang]

Ah, gotcha. I agree then.

[guangyang]

After trying the latest .NET SDK in more detail it seems like it is not, in fact, encoding by default although it exposes to option to deal with encoding. As such, we should do the same. Keep current behavior of not encoding and (potentially) add a encode / decode option.

[MiguelMadero]

Seems like .NET and even Azure Storage Explorer expect the string to be base-64 encoded.

[MiguelMadero]

The following code seems to fix the issue:

queue_service.create_message(queue_name, Base64.encode64(message))

[dmichael]

@MiguelMadero Thanks for posting this solution. I used this Gem just as it is described on the README, but the message placed on the queue was completely unreadable by the storage explorer or by my C# programs. If this is not a bug, then perhaps the README could be updated to reflect working usage of the Azure::QueueService ...

[MisinformedDNA]

Ah, I just ran into this as well. The same encoding should be used as the default for all SDKs. Why would we want different default encodings?

This also totally kills the ability to use the VS Azure Storage Explorer as it results in an error.