downloading a folder or multiple files with an android browser should return a ZIP file

[individual-it]

Is your feature request related to a problem? Please describe.

When trying to download multiple files with an browser on android, ocis presents a TAR file, I tried it on multiple phones and every time I had to install an extra app to open TAR files

Describe the solution you'd like

download the data as a ZIP file when requesting with Android

Describe alternatives you've considered

always download the data as a ZIP file, regardless of the
OR
make it configurable for the admin

Additional context

code path in question: https://github.com/cs3org/reva/blob/6748a5ff45e9a46b58af1f14421be150e88f8e3a/internal/http/services/archiver/handler.go#L254-L270

[AlexAndBear]

the api MUST allow a query parameter for the output format

[AlexAndBear]

blocking: owncloud/web#11080

[pascalwengerter]

the api MUST allow a query parameter for the output format

Is that the way to go? From what I have seen the existing code could also be modified to provide ZIP for Windows/Android/iOS/MacOS with tar as fallback (assuming it's a Linux client), which may be the "easier" solution?

[AlexAndBear]

the api MUST allow a query parameter for the output format

Is that the way to go? From what I have seen the existing code could also be modified to provide ZIP for Windows/Android/iOS/MacOS with tar as fallback (assuming it's a Linux client), which may be the "easier" solution?

Related web issue is about providing zip files on web for all sort of user-agents. So this is the way to go.
Fallback can be possible. But the API accepting a format output should be implemented

[AlexAndBear]

Decided with @kobergj and @kulmann that we will eliminate the output format via user agent, default will be zip, output format can be set via query param e.G output-format=zip or output-format=tar

We also need to adjust the documentation

[kobergj]

We decided to switch the default to .zip and remove the os specific logic. Clients can request .tar files if they want to.

Any objections against using the Accept header for this? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept
Or should we rather add a parameter for this endpoint specifically e.g. archive-type=zip ?

[AlexAndBear]

Much objections. Please just use the query Params. There are designed for that use case

[DeepDiver1975]

Any objections against using the Accept header for this? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept

accept header sounds reasonable

[AlexAndBear]

We build easy to use and document APIs. This is adding a unnecessary complex layer.

[DeepDiver1975]

Accept header is an integral part of the http standard which is the basis for REST.

But I don't care much. Just sharing perspectives. 🤷

[AlexAndBear]

A lot of out dated API designs are based on http

[jvillafanez]

Just leaving some thoughts here

The Accept request HTTP header indicates which content types, expressed as MIME types, the client is able to understand

The key point is "understand". This means that the client could do some preprocessing / analysis of the file if the server sends it in the requested format. If the client receives the content in a different / unexpected format, it could cause problems in the client.
In addition, if the server can't provide the content in the requested format (in the "Accept" header), the server should respond with the 406 (Not Acceptable) code.

For our particular case, I don't think the client needs to care about the specific format because it just needs to save whatever stream of bytes it receives. Our client doesn't need to "understand" the content.
It should be fine that, even if the client requests a ".zip" file, the server sends a ".tar" file for whatever reason. As long as it's documented that we'll try to send the right format but we could send a different one, it should be fine.

[AlexAndBear]

🙏

[kobergj]

@jvillafanez sorry I don't get it. Is that a +1 for the Accept-Header or for the archive-format query parameter?

[jvillafanez]

I'd vote for the archive-format with my reasoning above. We have more flexibility on how the behavior we want to have.

In addition, the Accept header can have multiple mimetypes with different priorities, so we'd need to handle those cases. Comparing that against a simple archive-format with just 2 or 3 possible values...