Service worker prevents Axios file upload progress

[mrcarl79]

Hi,

I have your react-oidc package working for our auth, but I've just noticed that file upload progress for our uploader has stopped working and I believe this is due to the service worker relaying the request.

I use Axios in this kind of way:
https://github.com/axios/axios/blob/master/examples/upload/index.html

It has a call back function that gives us the progress status, but this is now not being run.

I don't have a huge amount of experience with service workers or oidc security, but looking for a way to solve this.

Is this a feature that can be built into the service worker? or would another solution need to be found?

Thanks, Carl

[guillaume-chervet]

Hi @mrcarl79,

Thank you for the issue.

Do you have more information about what is not working? The error message, etc.
Does it work whithout the service worker?
What is the request content type?

[mrcarl79]

It is this FileReader event:
https://developer.mozilla.org/en-US/docs/Web/API/FileReader/progress_event

We have an API that accepts file uploads, we use Axios in our React project to post to our API and axios passes back this progress event which allows up to show a progress bar as large files upload.

There is no error message just this event gets ignored.

Yes it works without service worker.

The request content type is multipart/form-data.

Thanks, Carl

[guillaume-chervet]

Thank you for the information. I think i can investigate with that :)

[tiphaineruy]

Encountered the same issue while fetching a file. Had to disable the web worker as a workaround. Silent issue. wouldn't have found it without this post.

[tellaconz]

@guillaume-chervet Do you know if this is something that is an issue in the service worker? it's still a known issue on our project and I'd like to find a way to get our upload progress back

[guillaume-chervet]

Hi @tellaconz , yes this is still an issue. I do not have any project for the moment with file progress. I can set it up on an old one but it will require me some times.

[guillaume-chervet]

Thank you all for the issue. It will help to make the library better.

[guillaume-chervet]

It seems it is not so easy to resolve w3c/ServiceWorker#1141

[srinhari]

@guillaume-chervet , we are facing similar issue that the axios callback (on-progress) during multi-part upload is not being called, when the service worker is in use. Is there any fix available for this. If not, is there any workaround or quick-fix? Any help would be appreciated. Thanks.

[guillaume-chervet]

Hi @srinhari unfortunately it is a chrome bug.
I cannot do anything else than waiting for a fix from chrome.

In my application I have set a generic loader without progress bar for file upload.

[srinhari]

Thank you @guillaume-chervet for your response. Actually, we have tested with Firefox as well. The callback is not invoked on firefox as well. Does not seem to be a browser specific issue.

[VladimirPlatonenko]

Hi @srinhari unfortunately it is a chrome bug. I cannot do anything else than waiting for a fix from chrome.

It does not look like chrome specific bug, rather limitation of service workers in general.
Proper progress is very important for application we are building so as a workaround we access uploading endpoint bypassing service worker, e.g.:

• create single-use token by accessing one of endpoints that is behind SW;
• send second request to upload endpoint using this one off token,
  We have put quite a complex regex in trustedDomains to make sure second request is not upgraded by SW(e.g. to match paths of of particular url except specific one).
  Unfortunately this solution relies on string matching which is not very obvious. And of cause when recently we changed routing on back-end a little bit plus forgot to change url matching pattern and progress stopped working,
  To make things even worse we now have another endpoint with same url(using GET not POST) as uploading one. So we no longer can use url matching to distinguish upload endpoint.
  I have two possible solutions in mind:
• add ability to provide custom function to judge if request should be upgraded by SW as an alternative to just supplying trustedDomains;
• change SW to just ignore requests that already have Authorization header. Or alternatively use some other mean of communication(custom header??) that application wants request to bypass SW.

No matter which solution we choose I can quickly code it and submit PR. My personal preference will be option 2 as it is very clear what is happening and also it eliminates dependency on string matching\function in SW. You control all from the code when making request.

[VladimirPlatonenko]

@guillaume-chervet Any ideas or feedback on this? Right now we ended up using forked version of the library with option 3 from above implemented to support our workflow. Bu this is not ideal and I hope we can embed some of workarounds above into main stream so we can get regular updates from other contibuters

[guillaume-chervet]

Hi @VladimirPlatonenko , yes it seem to be a nice enhancement to complete regex and string match selector by a custom function selector. Do you have time to send a pullrequest ?

I am 2 weeks of and back in May

Thank you very much for all your feedbacks @VladimirPlatonenko and ideas. i'am pretty sure it will help for who will encounter the same problem.

[guillaume-chervet]

Hi @VladimirPlatonenko ,
I am not sure but i think we resolved your issue with letting the access token to not be hide for your specific use case?
The FAQ e plain now that service worker is not compatible with progress bar for file upload.

May we close this issue?