Answered

OneDrive Upload file from URL: Error - "Content-Length for source file is missing or invalid."

(3) Share

Report

Posted on by Cayshin

338

This error started occurring on a couple of my flows a few days ago. These flows had been running fine and unchanged for months.

Background: As a workaround to needing premium licenses for everyone using a specific PowerApp, in the flow connected to the PowerApp I use the OneDrive "Upload File from URL" action to trigger, pass, and retrieve data from a second "When a HTTP request is received" flow that has the premium actions.

Steps to recreate:

1) Start a new flow.

2) Change the trigger step to "When a HTTP request is received".

3) Set its advanced property "Method" to GET.

4) Add any other step just so it'll let you save, then save the flow.

5) "When a HTTP request is received" will now show a HTTP GET URL. Copy this URL.

6) Start another new flow.

7) Add a new action card "Upload File from URL".

8) Set its Source URL to the one copied in step 5. Additionally, append to the URL a query by putting anything like "&Test=12345" at the end of it. (in my example it's "&CustNo=T00211")

9) Set the "Destination File Path" to anything. It's irrelevant for this test.

10) Save & test this flow.

This returns the mentioned error that never used to happen.

if you change the "Upload file from URL" to something else - like the Microsoft logo from this forum https://community.powerplatform.com/microsoft-logo.png - then it runs fine.

Would anyone have any insight as to why the error has suddenly started happening?

Thanks

Categories:

Building flows

I have the same question (0)

All responses (5)

Answers (1)

Sort by

Suggested answer

Haque 3,197 on at

Like (1)

Report
Copy link

Link copied!

Hi @Cayshin,

I am suspecting the source URL does not provide a valid or explicit Content-Length header, which OneDrive requires to process the upload.

If the source is a flow HTTP trigger URL, consider changing the approach: instead of uploading from that URL("Upload file from URL"), fetch the file content in the flow (e.g., HTTP GET file content) and then upload using the file content action.

Then use the OneDrive "Create file" or "Upload file" action with the file content directly, rather than the URL.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
Cayshin 338 on at

Like (3)

Report
Copy link

Link copied!

So the "Create file" and "Upload file" won't work because that's not actually the goal of the flow.

To elaborate further, the final step of the "When a HTTP request is received" flow is a "Response" action.

The body of this response, just some basic JSON or string data, is what gets - or used to get - returned to the calling "Upload file from URL" action. That JSON/string data is then written to a file as part of the "Upload file from URL" action.

After the "Upload file from URL" is a "Get file content" to read the contents of that generated file. In this way, data from a Flow using premium actions can be indirectly passed back to a PowerApp-connected Flow thus subverting the need for all users of that app to have a premium license.

The "Upload file from URL" does work halfway. It is triggering the "When a HTTP request is received" flow and that flow completes with no issue.

I've tried adding a "Content-Length" header to the "Response", but the OneDrive still didn't like it.

Was this reply helpful? Yes No
Verified answer

11manish 2,293 on at

Like (0)

Report
Copy link

Link copied!

Your diagnosis is likely correct:

The OneDrive connector now appears to require a proper downloadable response with valid file semantics (especially Content-Length).

The Flow HTTP trigger endpoint no longer satisfies those expectations reliably.

Additionally, Microsoft may have tightened behavior around indirect premium connector usage patterns.

The solution worked previously because the connector was more permissive, but recent backend changes likely removed that tolerance.

The most reliable long-term fix is to redesign the communication pattern rather than continue depending on Upload File from URL as a transport mechanism

between flows.

Was this reply helpful? Yes No
Suggested answer

Haque 3,197 on at

Like (1)

Report
Copy link

Link copied!

Hi@Cayshin,

Thanks for the clarification.

Seems like adding the header in the flow response is not sufficient; the source URL must inherently serve a static or properly formatted downloadable file with correct HTTP headers.

So this is probably because OneDrive validates the file metadata directly from the URL's HTTP response, and if the underlying HTTP endpoint (your flow's HTTP trigger) does not reliably provide a proper Content-Length header or other file semantics, OneDrive will reject the upload.

By any chance the situation is deamnding premium connectors!

Was this reply helpful? Yes No
Cayshin 338 on at

Like (3)

Report
Copy link

Link copied!
@11manish - Thank you for that clarification. That explains it.... bummer.

Edit for future readers - I've found a much easier and native method that also bypasses the need to premium licenses for everyone.

Change the "When a HTTP Request is received" trigger to a regular "Manually trigger a flow".

Now put the associated Flows and app into a Solution.

In the flow with the "Upload file from URL" action that's connected to the app, you'll now have access to a "Run Child Flow" action that you can replace the Upload action with.

The response body of the "Run Child Flow" will contain whatever info you put in the "Response" action of the other flow.

Was this reply helpful? Yes No