Enable upload of compressed documents

[JimFuller-RedHat]

For example, we would like to upload compressed SBOM openshift-4.13.json.xz via SBOM ux.

[ctron]

The upload through the UI happens the same way other clients use the API. Now, the question is: how does the backend figure out its a compressed payload?

One way to deal with this would be to sniff for some magic bytes, detecting a compressed data stream.

Another way would be to evaluate the Content-Encoding or Content-Type header. Which would mean that the UI would need to set either header (<- @carlosthe19916). I am actually not sure which header to use in this case, as its not about the encoding of the file being uploaded, but the file itself.

In case of an unsupported type, we should return 415 (Unsupported Media Type).

[ctron]

Or maybe go for a combination: if the Content-Encoding header is present use it. Otherwise fall back to magic detection?

[ctron]

Ok, Content-Encoding seems to be out of the picture, because it doesn't support bz2.

[jcrossley3]

Not sure it's helpful, but we had this feature in v1

[carlosthe19916]

From the UI point of view, I think it is more than just uploading a compressed file and detecting its format. There are other aspects we would need to considerer e.g.

• What if the compressed file contains more than one file?
• What if only a subset of the files within the compressed file are accepted and the rest are rejected due to validation issues?
• Or do we create a constraint so only 1 file should be part of every compressed file? if more than one file is found, then we reject the whole upload?

We could add that feature on the backend side but I anticipate we will revisit the current UI Upload part of V1 (trustification)

[ctron]

Ok, Content-Encoding seems to be out of the picture, because it doesn't support bz2.

From the UI point of view, I think it is more than just uploading a compressed file and detecting its format. There are other aspects we would need to considerer e.g.

* What if the compressed file contains more than one file?

* What if only a subset of the files within the compressed file are accepted and the rest are rejected due to validation issues?

* Or do we create a constraint so only 1 file should be part of every compressed file? if more than one file is found, then we reject the whole upload?

We could add that feature on the backend side but I anticipate we will revisit the current UI Upload part of V1 (trustification)

This is only about compression. Not archives.

[ctron]

Not sure it's helpful, but we had this feature in v1

Yea, I think it would go in the same direction. Minus the Content-Encoding, as that doesn't seem like a good fit.

[ctron]

Closed by #799