Idea #22985
closed
Support accept=application/zip query param alternative for collection zip download
Description
The current implementation of collection zip file download requires sending a header of Accept: application/zip to signal intent to receive a zip file. Since sending headers like this requires ajax, it complicates the WB implementation and requires buffering the response in JS and makes it appealing to use a library to handle the complications.
If we can signal this intent using a query param for GET and either a query param for POST (not sure if that's 100% kosher) or json param for POST, it will significantly ease the implementation of the WB side and allow me to let the browser natively handle the file download process (via href or html form post triggered through JS).
Support the query param accept=application/zip as an alternative to using headers to signal this intent.
Updated by Stephen Smith 9 months ago
- Target version set to Development 2025-06-25
Updated by Brett Smith 9 months ago
- Target version changed from Development 2025-06-25 to Development 2025-07-09
Updated by Stephen Smith 9 months ago
- Blocks Feature #22831: Support for downloading multiple files as a zip file added
Updated by Brett Smith 9 months ago
Tom Clegg wrote in #note-4:
?accept=application/zipmight be a good choice in that it's more obvious how it maps to the header, and easily accommodates potential future variations like?accept=application/tar.
This sounds good to me, please go ahead with this implementation.
Updated by Brett Smith 9 months ago
- Description updated (diff)
- Subject changed from Support disposition=archive query param alternative for collection zip download to Support accept=application/zip query param alternative for collection zip download
Updated by Tom Clegg 9 months ago
22985-zip-via-query @ 84909a8ccf75288b1c83f05d3df7100b8db3f1b5 -- developer-run-tests: #4823
retry fuse run-tests-doc-pysdk-api-fuse: #1045
Updated by Tom Clegg 9 months ago
- All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
- ✅
?accept=application/zipnow overrides Accept header - ...but only if keep-web is going to send a
Content-Disposition: attachmentresponse header. I added this condition because it seems a little sketchy to ignore the UA's Accept header for inline content (showing a zip file as inline content doesn't seem like a real use case anyway). So, in practice, the "request zip file" URI will specify both params explicitly:?accept=application/zip&disposition=attachment
- ✅
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- n/a
- Code is tested and passing, both automated and manual, what manual testing was done is described.
- ✅ added test cases
- New or changed UI/UX has gotten feedback from stakeholders.
- n/a
- Documentation has been updated.
- ✅ I simplified the docs to just
?accept=application/zip&disposition=attachmenteven though it also works to say just?accept=application/zipwhen using the attachment-only (WebDAVDownload) URL.
- ✅ I simplified the docs to just
- Behaves appropriately at the intended scale (describe intended scale).
- ✅ No scaling consequences
- Considered backwards and forwards compatibility issues between client and server.
- ✅ No compatibility issues
- Follows our coding standards and GUI style guidelines.
- ✅
Updated by Brett Smith 9 months ago
Tom Clegg wrote in #note-8:
22985-zip-via-query @ 84909a8ccf75288b1c83f05d3df7100b8db3f1b5 -- developer-run-tests: #4823
LGTM, thanks.
Updated by Tom Clegg 9 months ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|dfa05991e9a94bbcfc3a717ebeb4da58dec34d16.