Creator Companion

[Bug] Missing content-disposition filename seems to break importing a package
I have two gitlab links, one returns a content-disposition header whereas the other does not. The one without content-disposition fails to be properly imported via VCC, even though the NUKE build reads it properly and it is correctly listed as a selectable version in the dropdown. With: https://gitlab.com/techanon/protv/-/releases/v3.0.0-beta.18/downloads/package Without: https://gitlab.com/techanon/protv/-/releases/v3.0.0-beta.20/downloads/package With a curl -I command, you will notice these are redirects. I post the original link as it is relevant to my repro. Redirect target with content-disposition: https://gitlab.com/techanon/protv/uploads/e0b1df0c8c7c162de876489f75ebd199/ArchiTech.ProTV_v3.0.0-beta.18.zip Redirect target without content-disposition: https://gitlab.com/api/v4/projects/27741679/packages/generic/ArchiTech.ProTV/v3.0.0-beta.20/ArchiTech.ProTV_v3.0.0-beta.20.zip The working package link was published using gitlab's file upload API (typically used for uploading files for a changelog or release info). The other was uploaded to the gitlab package storage. I recently switched from the upload API to the package storage due to some recent instabilities with gitlab's upload API returning 404, so I had to find a solution and landed on the package api. For full context here are the CI scripts used for each: upload api: https://gitlab.com/techanon/protv/-/blob/v3.0.0-beta.18/.gitlab-ci.yml package api: https://gitlab.com/techanon/protv/-/blob/v3.0.0-beta.20/.gitlab-ci.yml My observation of the failure is that because there is no content-disposition defining the filename on the redirect, VCC implicitly uses the end of the file path for the initial URL as the file name when downloading it into the file cache. I confirmed this when checking the %APPDATA%\Local\VRChatCreatorCompanion\Repos\dev.architech.protv folder and the newer version was downloaded as just package . So when VCC tried to read the downloaded file, it failed for whatever internal reason. I updated the source.json for the listing with the redirect target url, the one with the file name at the end, and that allowed VCC to pull in the release correctly. I think if a content-disposition is not provided, VCC should look through the possible redirect stack to find a path that ends in a .zip name. Or maybe to keep things simple, if no content-disposition is available, implicitly download the file as {package.displayName}_v{package.version}.zip instead of the ending path segment name.
0
Load More