cmd-buildupload: Set Content-Type and Content-Encoding headers#862
cmd-buildupload: Set Content-Type and Content-Encoding headers#862jlebon merged 1 commit intocoreos:masterfrom
Conversation
jlebon
force-pushed
the
pr/fix-content-type
branch
2 times, most recently
from
cbd66eb to
661cbe9
Compare
|
where are we on this? a few outstanding comments? |
Automatically detect the type of data being uploaded and set the
`Content-{Type,Encoding}` headers accordingly if not overriden.
This allows one to do `curl --compressed` to decompress on the fly. Note
we don't automatically do the `Content-Disposition: inline; filename=`
trick; this was found to be more confusing than useful in practice.
Closes: coreos/fedora-coreos-tracker#295
jlebon
force-pushed
the
pr/fix-content-type
branch
from
661cbe9 to
61b5442
Compare
|
OK, updated this! ⬆️ |
|
So this turned out to be another change for how RHCOS ships qcow2 images and broke some OpenStack code trying to download it. Previously, RHCOS switched to match FCOS in having an explicit One argument made in chat about this is that using both is wrong. The reason this breaks is because the Golang HTTP stack will transparently decompress if it detects Probably...we should just revert this and stop trying to use headers entirely? |
coreos#862 (comment) This regressed OpenShift on OpenStack installs, which had adjusted to deal with the lack of `Content-Encoding` and a switch to add `.gz` to images. Basically, if we're going to say things are explicitly compressed, let's not also tell people to *transparently* decompress them because it's easy to end up with a file named `.gz` that was decompressed.
|
Yeah the problem is we made changes now to consume the qcow2.gz files, but there are still some curl --compressed calls which have now started unzipping the qcow2.gz files, so the later explicit gz fails. IMHO we should pick one approach or the other, and since we've already dealt with the fallout of moving away from transport level compression, it seems reasonable to stick with the file extension approach consistently? |
#862 (comment) This regressed OpenShift on OpenStack installs, which had adjusted to deal with the lack of `Content-Encoding` and a switch to add `.gz` to images. Basically, if we're going to say things are explicitly compressed, let's not also tell people to *transparently* decompress them because it's easy to end up with a file named `.gz` that was decompressed.
5 participants
Automatically detect the type of data being uploaded and set the
Content-{Type,Encoding}headers accordingly if not overriden.This allows one to do
curl --compressedto decompress on the fly. Notewe don't automatically do the
Content-Disposition: inline; filename=trick; this was found to be more confusing than useful in practice.
Closes: coreos/fedora-coreos-tracker#295