Azure-docs: -The Azure Functions runtime uses this storage account connection string for all functions except for HTTP triggered functions.

[sbrian26]

Why not use AzureWebJobsStorage setting for HTTP triggered functions? This would make connecting to azure storage more convenient in HTTP triggers. That said, It's not very clear how to even access other settings in a HTTP trigger, what is the best practice to store the storage connection string in a HTTP trigger?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 18aa54fd-3aa1-37c5-925c-51a0195b1030
• Version Independent ID: 60198016-1ea9-e7ae-b00b-2c665d5ad8ca
• Content: App settings reference for Azure Functions
• Content Source: articles/azure-functions/functions-app-settings.md
• Service: azure-functions
• GitHub Login: @ggailey777
• Microsoft Alias: glenga

[BryanTrach-MSFT]

@sbrian26 Thanks for the feedback! We are currently investigating and will update you shortly.

[KetanChawda-MSFT]

@sbrian26 The AzureWebJobsStorage connection string is your Azure Storage Account that is used to by the runtime to do things like trigger when a file is uploaded to blob storage or a message is added to a storage queue. Azure Function runtime doesn't require storage connection string if the function is purely HTTP Triggered. If you have any other type of trigger or binding in your azure function than it is required.

[KetanChawda-MSFT]

@sbrian26 Checking in to see if the above post helped answer your question. Let me know if there are still any additional issues I can help with.

[sbrian26]

Yes thank you, I did eventually reach that conclusion and subsequently discovered how to access blob storage from the http trigger; As a matter of fact, at this time, there's not much documentation or example on how to access blob storage from an azure HTTP trigger function, my first notion was to just introduce the Storage Account via dependency injection in the function spec, this of course does not work. Could it (some day)? -- Since my function access the same blob container on each call, it would be nice to have a singleton service injected so as not to have to recall the setting, open the storage and container reference each function call.

[ggailey777]

@sbrian26 if your function accesses the same blob container, why not use a Blob storage input binding? The following is the definition for a compiled C# function that gets a value from the URL path (route) and uses that value as the name of a blob in a container:

[FunctionName("HttpTest")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = "httptest/{blobname:alpha}")] HttpRequest req, 
    [Blob("container/{blobname}.jpg", FileAccess.Read)] Stream myBlob, 
    ILogger log)
{
    ...
}

The URL would look like: http://<myfunctiondomain>/api/httptest/<image_filename>, which resolves to container/<image_filename>.jpg to return the requested Blob.

[sbrian26]

Yes, that's what I need, and hmm... actually, it was my first inclination to inject the blob dependency; I couldn't get it to work and then thought I read that the Blob parameters were not available to HttpTriggers.… After closer read of KetanChawda-MSFT's comment, perhaps I'm misinterpreting that as he says explicitly [not available "if the function is purely HTTP Triggered"] thanks for the reference, perhaps I just had the syntax wrong and gave up too early - I'm trying this again.

[sbrian26]

I've confirmed this works, the 1st go around I had neglected to add the microsoft.azure.webjobs.extensions.storage dependency.

[ggailey777]

@sbrian26 our docs are not good for this basic scenario. I've opened an internal work item (1459118) to address this issue. Thanks for pointing out this content gap!

cc. @craigshoemaker