Cannot download differentially, fallback to full download: Error: Content-Type "multipart/byteranges" is expected #5758
Comments
|
Would you be willing to submit a PR for this? Easy way to set up your dev environment for local testing with your project: https://github.com/electron-userland/electron-builder/blob/master/CONTRIBUTING.md#to-setup-a-local-dev-environment |
|
Thanks for the label, but it's not my first issue - I already submitted some improvements to Electron-builder: #4517 |
|
Sorry, I was not describing this as a good first issue for you specifically. |
|
For now, I managed to build a workaround - by slightly modifying a "byte-serving PHP script" I found online (it just needs a one-line tweak to always send the multi-range variant, even if just 1 range is requested). Combined with a .htaccess redirect, it transparently serves specific files in a way Electron understands. |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
It's still outstanding, still a problem. Can be worked around, but in an
ugly manner.
(And what's with the stale-closing? How on Earth is an issue fit for being
closed if it's still a problem, and just no-one got around to fixing it so
far?)
|
|
Few notes.
|
|
I didn't mean to sound entitled, as for points 1 and 3, I wasn't insisting
that you go and fix this now, I was just genuinely surprised issues are
(commonly on GH, seeing as the StaleBot is a rather standard fixture) so
readily allowed to be closed out of inaction. It's completely off topic, of
course, but I just wonder why not keep such issues open - for a long time,
maybe. Who knows, maybe you or some new contributor would eventually take
it up, for lack of better things to do? Is there some sort of anathema on
projects having many old issues, open since forever and still
causing problems every once in a while, but minor enough not to have
sparked interest?
…On Sat, 24 Jul 2021 at 17:11, Mike Maietta ***@***.***> wrote:
Few notes.
1. You're encouraged to contribute again to this project
Would you be willing to submit a PR for this?
1.
Backlog items are marked stale; backlog should always be "cleaned". As
in, what *we* work on is based on what *we* (2 maintainers + the
community) are able, or willing, to work on. If an issue has a high impact
on many many users, based on comments in a particular Github ticket, then
it's more likely we'll get to it. If we'll never get to it, then it's
marked stale and will eventually be closed. Closing backlog items
represents to the community that the specific ticket will not be worked on.
2.
Maintaining an open-source project is not a job, it's voluntary and
contributions are in our free time.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5758 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3QELMHSWM5F5E2RXPPG2TTZLJ3JANCNFSM42HWOVWA>
.
--
Adam "Sinus" Skawiński
|
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
(Not the newest versions, but the code in question hasn't changed since.)
Electron-Updater's multipleRangeDownloader expects a
Content-Type: multipart/byteranges; boundary=aaaaaaaaaaaaheader when it decides whether the server supports multiple downloads or not. However, if there is just ONE chunk of download, the server would respond withContent-Type: x-something/randomandContent-Range: bytes 1111-2222, properly indicating a single-chunk partial - and that's something multipleRangeDownloader doesn't recognize as valid, resulting in a fallback to a full download in a possibly very favorable, small, single-chunk update situation.Proper behavior would be to check (just in case) if
Content-Rangeis a single chunk, and then allow the partial download.One could set
useMultipleRangeRequestto false to circumvent the problem, but it would negate the benefit of a multipart download in non-single-chunk cases.I suspect inventing a boundary string and adding a proper byteranges wrapper to incoming data, then feeding it to DataSplitter (
multipleRangeDownloader.ts:104), would do the trick, but I don't have the means to build a proper test at the moment.The text was updated successfully, but these errors were encountered: