The Content-Range header length does not match the provided number of bytes when uploading chunks to OneDrive

[thewebartisan7]

UPDATE: The original issue that happen with bluebird (http://bluebirdjs.com/docs/error-explanations.html#error-the-promise-constructor-cannot-be-invoked-directly) doesn't happen with Vite, so I suppose is something unrelated with Uploady.
So the title has been updated with another issue that occur when uploading to OneDrive.

With below setup for chunked upload with OneDrive, I am getting below error:

Unhandled rejection TypeError: the promise constructor cannot be invoked directly

The HTTP request is not even sent.

import * as React from 'react';
import ChunkedUploady, { useItemProgressListener } from "@rpldy/chunked-uploady";
import { asUploadButton } from "@rpldy/upload-button";
import { Button, type ButtonProps } from '../UI/Button'

type OneDriveUploaderProps = {
	saveUrl: string;
	accessToken: string;
};

const UploadButton = asUploadButton((props: ButtonProps) => (
	<Button {...props}>Upload</Button>
));

const LogProgress = () => {
	useItemProgressListener((item) => {
		console.log(`>>>>> (hook) File ${item.file.name} completed: ${item.completed}`);
	});

	return null;
}

export const OneDriveUploader = ({ accessToken, saveUrl }: OneDriveUploaderProps) => {
	return (
		<ChunkedUploady
			debug
			destination={{
				url: saveUrl,
				headers: {
					Authorization: `Bearer ${accessToken}`,
					'Content-Type': 'text/plain'
				}
			}}
			chunkSize={5120000}
			multiple
			grouped
			maxGroupSize={2}
			method='PUT'
		>
			<LogProgress />
			<UploadButton />
		</ChunkedUploady>
	)
}

[yoavniran]

Hey @thewebartisan7

This error is strange, I cant tell why you'd specifically get it. Which Uploady version are you using?

A couple of things:

The first thing that immediately jumps at me is your configuration of grouped requests.
Chunked Uploady does not support grouped uploads as the docs mention:

(just saw the example in that page incorrectly used "grouped" config, so i removed it now)

Another issue that might be important in the context of chunked uploads, is that typically you're required to supply a header with a unique value to help the server distinguish between chunks. You can use the useRequestPreSend hook for that if its needed.
There's an example in this guide.

These issues shouldn't result in the error you're getting. If you can, please provide a reproducing sandbox and I'll take a look.

[thewebartisan7]

Hi @yoavniran thanks for your reply.

Yes I saw it and I also tried without group and the actual code is:

import ChunkedUploady, { useRequestPreSend } from '@rpldy/chunked-uploady';
import UploadButton from '@rpldy/upload-button';

type OneDriveUploaderProps = {
    saveUrl: string;
    accessToken: string;
};

const UploadButtonWithUniqueIdHeader = () => {
    useRequestPreSend(async () => {
        return {
            options: {
                destination: {
                    headers: {
                        'X-Unique-Upload-Id': `example-unique-${Date.now()}`,
                    },
                },
            },
        };
    });

    return <UploadButton />;
};

const OneDriveUploader = ({ accessToken, saveUrl }: OneDriveUploaderProps) => {
    return (
        <ChunkedUploady
            debug
            destination={{
                url: saveUrl,
                headers: {
                    Authorization: `Bearer ${accessToken}`,
                    //'Content-Type': 'text/plain'
                },
            }}
            chunkSize={5120000}
            chunked={true}
            //multiple
            method='PUT'
        >
            <UploadButtonWithUniqueIdHeader />
        </ChunkedUploady>
    );
};

I tried to create a reproducing repo with vite and now I am getting another error, coming from OneDrive.. much better than before ))

The error said:

Object { code: "invalidRequest", message: "The Content-Range header length does not match the provided number of bytes." }

Since the code require an access token to upload on OneDrive, I have upload everything in a private repo and I can give you access to it, where you can find also a working accessToken and temporary upload URL. Both should be valid around 1 hour, so in case this expire before, let me know and I can generate and update a new one. Let me know if you want to check or if you already can catch the problem with above code.

The previous error was with webpack, coming from bluebird.js which seem being used by webpack or something else, because is not in any of my dependencies, so I am not sure from where is coming.

[thewebartisan7]

I think this headers and request is also useful to understand the error:

[thewebartisan7]

I found out that the Content-Length is always higher than Content-Range by 186B in Chrome and 220B in Firefox.
For test this I used a file that fit in one chunk.

For example:

Content-Length: 3793061
Content-Range: bytes 0-3792874/3792875

The file size is 3792875.
The content length is always higher by 186B in Chrome / 220B in Firefox.

[thewebartisan7]

Just an update. I tested the upload with custom code, means without Uploady and it works fine. I notice that with Uploady it add in request payload additional data such as Content-Disposition and Content-Type, perphase maybe this add additional 186B / 220B ?

See screenshot:

[yoavniran]

can you share the custom code you've used to upload? I'll compare the differences
From a little reading I did, it does seem to be related to use of Formdata and multipart request.
Multipart does include extra information in the request, so it makes sense the total content-length is higher than the bytes of the file being sent. From what I've seen before, servers know to ignore this but apparently the Onedrive/Azure server isnt...

[thewebartisan7]

This is the screenshot of error that happen on main project with webpack:

But considering that this doesn't happen with vite, the problem seem to be somewhere else.
As I said before, I am not sure from where is coming this bluebird.js

[yoavniran]

hey @thewebartisan7
thanks for all of the follow up information. It certainly looks like something to investigate. I will take a look as soon as I can.
Chunked uploads have been working for a long time so it might be related to some extra strictness on the OneDrive side.

As for the promise error, again strange but its been a very long time since I saw someone use bluebird, thats the Promise polyfill, right?

[thewebartisan7]

As for the promise error, again strange but its been a very long time since I saw someone use bluebird, thats the Promise polyfill, right?

Yes right.. I found that is being used by an old version of Ajv package that we are using.

[thewebartisan7]

can you share the custom code you've used to upload? I'll compare the differences From a little reading I did, it does seem to be related to use of Formdata and multipart request. Multipart does include extra information in the request, so it makes sense the total content-length is higher than the bytes of the file being sent. From what I've seen before, servers know to ignore this but apparently the Onedrive/Azure server isnt...

Check here the gist https://gist.github.com/thewebartisan7/aa632ddf69f64c26f8abc5d90db50e1c
There is three files, a class for handle upload, a small wrapper for fetch and the component that show how to use it.
In case I can push in the existing repo so that is quicker to assemble a working test.

However, I think that is exactly as you said. When sending with FormData it add additional content and such is increasing the length. While in my case I am just sending the File or Blob directly in the body of fetch.

[yoavniran]

In that case, I suggest you try the sendWithFormData prop with false value:

<ChunkedUploady 
      destination={{ ... }}
     sendWithFormData={false}
>
...

This will turn off formData and should send it as your test code.

[thewebartisan7]

Yes this definitely make it works. Thank You!