I am trying to access a data storage of the azure stack. The following instructions work:
BlobClient = StorageAccount.CreateCloudBlobClient();
CloudBlobContainer myContainer = BlobClient.GetContainerReference("mycontainer");
But it crashes, when creating the Blob via myContainer.CreateIfNotExists():
...StatusMessage:The value for one of the HTTP headers is not in
the correct format.\r\n ErrorCode:\r\nErrorMessage:The value for one
of the HTTP headers is not in the correct format.\n
RequestId:"hiddenId"...
The behavior is exactly the same for Queues and Tables.
I tried the "Microsoft.WindowsAzure.Storage" library in its older version 7.2.1, version 8.7 and the current version 9.1. (8.7 should be fine regarding this documentation. Another documentation even sais, that every version between 6.2.0 and 8.7.0 should be compatible. 9.1 is not supported for sure.) In the end it is always the above error.
The code runs fine when targeting public Azure storages instead Azure Stack storages.
So I finally found out the solution with kind support of Microsoft.
It was indeed a versioning problem, one can find out when understanding this documentation the right way.
I am using Azure Stack version 1.0.180103.2. This is the internal version number an means it has been created on the 3rd of January 2018. This refers to version 1801, in the versioning scheme used within the documentation.
The API version 8.7 is only valid from 1802 on. So I have to look at the bottom of that documentation page under "previous". And there one can see that I have to go back to "Microsoft.WindowsAzure.Storage" library 6.2. Using this library it works.
This error could be a result if BlobRequestOptions and OperationContext have not been set, Could you provide values to both then check again? The documentation can be found here: https://learn.microsoft.com/en-us/dotnet/api/microsoft.windowsazure.storage.blob.cloudblobcontainer.createifnotexists?redirectedfrom=MSDN&view=azure-dotnet#overloads
Related
I'm running an Azure function in Azure, the function gets triggered by a file being uploaded to blob storage container. The function detects the new blob (file) but then outputs the following message - Did not find any initialized language workers.
Setup:
Azure function using Python 3.6.8
Running on linux machine
Built and deployed using azure devops (for ci/cd capability)
Blob Trigger Function
I have run the code locally using the same blob storage container, the same configuration values and the local instance of the azure function works as expected.
The functions core purpose is to read in the .xml file uploaded into blob storage container and parse and transform the data in the xml to be stored as Json in cosmos db.
I expect the process to complete like on my local instance with my documents in cosmos db, but it looks like the function doesn't actually get to process anything due to the following error:
Did not find any initialized language workers
Troy Witthoeft's answer was almost certainly the right one at the time the question was asked, but this error message is very general. I've had this error recently on runtime 3.0.14287.0. I saw the error on many attempted invocations over about 1 hour, but before and after that everything worked fine with no intervention.
I worked with an Azure support engineer who gave some pointers that could be generally useful:
Python versions: if you have function runtime version ~3 set under the Configuration blade, then the platform may choose any of python versions 3.6, 3.7, or 3.8 to run your code. So you should test your code against all three of these versions. Or, as per that link's suggestion, create the function app using the --runtime-version switch to specify a specific python version.
Consumption plans: this error may be related to a consumption-priced app having idled off and taking a little longer to warm back up again. This depends, of course, on the usage pattern of the app. (I infer (but the Engineer didn't say this) that perhaps if the Azure datacenter my app is in happens to be quite busy when my app wants to restart, it might just have to wait for some resources to become available.). You could address this either by paying for an always-on function app, or by rigging some kind of heartbeat process to stop the app idling for too long. (Easiest with a HTTP trigger: probably just ping it?)
The Engineer was able to see a lower-level error message generated by the Azure platform, that wasn't available to me in Application Insights: ARM authentication token validation failed. This was raised in Microsoft.Azure.WebJobs.Script.WebHost.Security.Authentication.ArmAuthenticationHandler.HandleAuthenticate() at /src/azure-functions-host/src/WebJobs.Script.WebHost/Security/Authentication/Arm/ArmAuthenticationHandler.cs. There was a long stack trace with innermost exception being: System.Security.Cryptography.CryptographicException : Padding is invalid and cannot be removed.. Neither of us were able to make complete sense of this and I'm not clear whether the responsibility for this error lies within the HandleAuthenticate() call, or outside (invalid input token from... where?).
The last of these points may be some obscure bug within the Azure Functions Host codebase, or some other platform problem, or totally misleading and unrelated.
Same error but different technology, environment, and root cause.
Technology Net 5, target system windows. In my case, I was using dependency injection to add a few services, I was getting one parameter from the environment variables inside the .ConfigureServices() section, but when I deployed I forget to add the variable to the application settings in azure, because of that I was getting this weird error.
This is due to SDK version, I would suggest to deploy fresh function App in Azure and deploy your code there. 2 things to check :
Make sure your local function app SDK version matches with Azure function app.
Check python version both side.
This error is most likely github issue #4384. This bug was identified, and a fix was released mid-june 2020. Apps running on version 3.0.14063 or greater should be fine. List of versions is here.
You can use azure application insights to check your version. KUSTO Query the logs. The exception table, azure SDK column has your version.
If you are on the dedicated App Service plan, you may be able to "pull" the latest version from Microsoft by deleting and redeploying your app. If you are on consumption plan, then you may need to wait for this bugfix to rollout to all servers.
Took me a while to find the cause as well, but it was related to me installing a version of protobuf explicitly which conflicted with what was used by Azure Functions. Fair, there was a warning about that in the docs. How I found it: went to <your app name>.scm.azurewebsites.net/api/logstream and looked for any errors I could find.
I am trying to use the new AppendBlob
This is my code:
CloudAppendBlob appendBlob = container.GetAppendBlobReference("MyDir/MyKey");
if (!appendBlob.Exists())
{
appendBlob.CreateOrReplace();
}
return appendBlob.AppendTextAsync("someText");
If I do DownloadText on the given reference I see the text I put in ("someTextsomeTextsomeTextsomeText").
But if I go to the portal to see the blob I get the error message "Cannot load management data for the current view."
And if i try to use the storage explorer I get "The remote server returned an error: (409) Conflict."
Can anyone explain these errors to me and how to resolve them?
Thanks!
Support for Append Blob is introduced in Storage Service REST API Version 2015-02-21. Storage Client library version 5.0.0 has support for this REST API version.
The reason you're getting this error is most likely because these tools are not updated to make use of latest version of REST API/Storage Client library.
One thing you could do is contact the owners of these tools and ask them to update the code to make use of latest version of REST API/Storage Client library. Azure Storage Explorer is open source so you may want to take the code and update it so that it makes use of the latest library.
If you're looking for other tools, you can either look at Cloud Portam [Disclaimer: I am building this tool] (http://blog.cloudportam.com/announcing-support-for-append-blobs-in-cloud-portam/) or Azure Management Studio. Both of these tools have full support for Append Blobs.
Team,
I am a beginner in Azure and have some queries regarding the blob storage logs
I am referring to this link http://blogs.msdn.com/b/windowsazurestorage/archive/2014/08/05/microsoft-azure-storage-service-version-removal.aspx
Now in my test environment I have enabled logging and I have got access to the log folders via Azure Management Studio.
When I look in the folders there are several mini folders I guess differentiated hr by hr. In that there are small txt files which get generated every 10 mins.
First question: How come the logs get generated even though there is no web activity ?
Second question : I have a problem with the storage version. The link given above talks about removing version before 2012. Does that mean I should only look at GetBlob/GetTable requests ? The reason I am asking this is because along with the first Getblob request you have another request which is ListBlobs,Releaseblobs each with different version;
for eg
1.0;2015-01-22T09:25:05.1660119Z;ReleaseBlobLease;Success;200;8;8;authenticated.......;;; having version 2011-08-18
1.0;2015-01-22T09:26:51.2674946Z;ListBlobs;Success;200;4;4;authenticated;;autoenrolmenttest;blob...... having version 2012-02-12
1.0;2015-01-22T09:22:18.6111213Z;PutBlob;Success;201;13;12;authenticated;......... having version 2011-08-18
1.0;2015-01-22T09:25:06.0485334Z;GetBlob;Success;200;53;52;authenticated;....having version 2011-08-18
My predicament is which version I should consider from the above 4 ? Only getbllob?
1) Logs containing requests certainly mean that there is an activity in your Azure Storage account. You can look at the client IP address to figure out where those requests are coming from.
2) Requests are independent and thus can be executed with different versions. All requests with an older version will not work after the version removal.
I am developing an Azure website, and I want to make use of Blob storage. I am using VS2013, Azure SDK 2.2. I have tried Azure Storage 2.1.0.4 from NuGet, I have tried using the latest 3.0.2.0 too. I have upgraded the emulator to the latest preview version 2.2.1, I was using 2.2.0 before.
My issue is, it doesnt matter if I point at the emulator or real storage, I get Bad Request 400 errors (invalid headers).
I set up a really simple form application, with a single button to make this easy.
private void button1_Click(object sender, EventArgs e)
{
var account = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("StorageConnectionString"));
CloudBlobClient blobClient = account.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("UserImages");
if (!container.Exists())
{
container.Create();
container.SetPermissions(new BlobContainerPermissions { PublicAccess = BlobContainerPublicAccessType.Off });
}
}
Everything looks good until container.Exists() executes, and then I get an unhandled error (Bad Request 400). I have tried a few different operations and I get the same unhelpful message every time.
I am storing the Azure Connection string in the appSettings section, and in this simple example I have tried pointing at a real Storage Account, and the emulator, and I get the 400 error every time.
My config file has this:
<appSettings>
<add key="StorageConnectionString" value="DefaultEndpointsProtocol=https;AccountName=[MyAccountName];AccountKey=[MYREALKEY]" />
</appSettings>
Using the Server Explorer in VS2013, I can happily connect to both the Emulator and real storage, and access Blob storage without issue.
This is effectively stopping me adding the ability to my site to upload files to the storage account.
Anyone else having this problem? As far as I know, I have tried older versions and the latest versions of the important components. I have always had SDK 2.2 though.
Any suggestions gratefully received.
For information, I followed this example, which I found in the Azure management portal:
http://www.windowsazure.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs-20/
Thanks
Ian
To see naming rules, please check out this link: http://msdn.microsoft.com/en-us/library/windowsazure/dd135715.aspx. From this documentation page:
A container name must be a valid DNS name, conforming to the following
naming rules:
Container names must start with a letter or number, and can contain only letters, numbers, and the dash (-) character.
Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in
container names.
All letters in a container name must be lowercase.
Container names must be from 3 through 63 characters long.
Regarding getting 400 error with storage emulator, please check the storage client library version. If it's 3.x, then you would need to install storage emulator 2.2.1 released in preview today. More information about this can be found here: http://blogs.msdn.com/b/windowsazurestorage/archive/2014/01/16/windows-azure-storage-emulator-2-2-1-preview-release-with-support-for-2013-08-15-version.aspx
This drove me insane for two days. Installing/Uninstalling the SDK, emulators, Azure Storage NuGet packages etc. I finally got the emulator working as well as real storage. The MSI you download to install the preview version of the emulator 2.2.1 contains a readme - I didnt know it was there, but it contains some pretty important instructions!
3. Copy all files from the following path:
For 32-bit OS: "%ProgramFiles%\Windows Azure Storage Emulator 2.2.1\devstore"
For 64-bit OS: "%ProgramFiles(x86)%\Windows Azure Storage Emulator 2.2.1\devstore"
to the following path:
"%ProgramFiles%\Microsoft SDKs\Windows Azure\Emulator\devstore"
If prompted, choose to replace the existing files with the new ones.
It turns out the MSI doesnt update the files actually used by the emulator at run time! You have to perform this task by hand. I feel sooo stupid for not seeing this basic instruction. Turns out RTFM was the answer!
ImageResizer is running as an Azure virtual application (after ImageResizer hotfix). This runs fine in Azure emulation but is having problems in Azure cloud. Image Resizer is working fine if no query string arguments are specified and the url redirects to blob storage, but if a query string argument is specified then I receive a 400 "Bad Request" error.
Below is a screenshot of my browser:
My Azure instance is running Windows Server 2012. I have also disabled the DiskCache plugin to reduce the problem.
I got the same problem as You. I used fiddler to see if I could figure out what went wrong and I think I fixed it. It's a problem with AzureReader2 and how it concatenates URL'S.
A specific example from fiddler is this URL: http://xxx.blob.core.windows.net//card-images/14_main_image.png
As you can see it got two slashes in a row which gives you the 400 "bad request".
I downloaded the sourcecode for AzureReader2 and replaced all occurrences of "CloudBlobClient.BaseUri.OriginalString" with "CloudBlobClient.BaseUri.OriginalString.TrimEnd('/', '\')"
I don't know if it's the best fix, but at least it's working until a better fix comes. If you are interested, I can send you the compiled dll.
Best Regards
Martin
I would have added this as a comment in reply to user2486535, but my StackOverflow rep is not sufficient for posting comments yet...
You are probably getting the 400 Bad Request at this time because the latest version of Microsoft.WindowsAzure.Storage (3.0.2.0) is not compatible with the current Storage Emulator released with the Windows Azure SDK (2.2).
It's explained at the bottom of this article, under "Storage Emulator Guidance":
http://blogs.msdn.com/b/windowsazurestorage/archive/2013/11/27/windows-azure-storage-release-introducing-cors-json-minute-metrics-and-more.aspx
As of January 27, Microsoft has released a preview version of the Windows Azure Storage Emulator (2.2.1) that is compatible with Microsoft.WindowsAzure.Storage (3.0.2.0):
http://blogs.msdn.com/b/windowsazurestorage/archive/2014/01/27/windows-azure-storage-emulator-2-2-1-preview-release-with-support-for-2013-08-15-version.aspx
Hopefully this helps you get by until the next official release of the Windows Azure SDK.