Incorrectly reported application/octet-stream for GENERIC_PACKS using Alpine images

[Yokutto]

Enhancement Type

Improve an existing feature

Describe the enhancement

Yep, the title says it all.

Can we consider allowing application/octet-stream content-type for GENERICK_PACK/GENERICK_PACKS?

At current time, it fails with:

[init] Checking if generic packs are up to date
[init] Generic pack(s) are out of date. Re-applying...
[init] [ERROR] Unsupported archive type: application/octet-stream

[Yokutto]

I saw the source code function that decompress things, and I think it makes sense not allowing application/octet-stream, but can we at least fallback to file extension?

[itzg]

Yes it's a good request. Some web servers certainly fallback to octet stream for zip files.

[Yokutto]

Thanks for considering my suggestion. But, before we implement something like this, we should consider how we will actually do it.

Since application/octet-stream can represent literally anything per definition, we need at least a hint of what file we are dealing with

For this, I think we have two main approaches:

1. Extracting the file extension from the file we downloaded:

I'm not sure if the "download util" follows the filename convention of Content-Disposition header. Also, parsing anything from URLs is too painful. Thinking of that, we should consider extracting the extension from the downloaded file itself, since we will already download it anyways

2. Reading its file signature:

Another option is to examine the file's metadata (its initial bytes) and match them against known file signatures. I think this is the most reliable and consistent method. Unix-based images even include the head command (including Alpine), although I'm not sure if this command is available on the images we are using for this project

[itzg]

You might be overthinking it 😄 If the downloaded file is not a proper zip file, then the zip file extraction will fail since it itself will perform file/header inspection. So, I'd prefer to let the JDK throw the exception rather than jumping through extra complexity to arrive the same outcome: indicating to the user that the file is not a valid zip file. I can have the code catch and massage the JDK level exception into a cleaner, user facing one to clarify the invalid file type.

[itzg]

...and now that I look at the source code closer, it's using a file inspection:

docker-minecraft-server/scripts/start-utils

Line 425 in dcdbb85

type=$(file -b --mime-type "${src}")

to determine the content of the file and has nothing to do with what the web server reported.

Are you certain the file you're referencing is actually a zip (or other compressed) file? Can you provide the URL?