You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently switched to the requests library in oz. This works fine for the most part but the requests library has an interesting (and mostly useful) feature where The gzip and deflate transfer-encodings are automatically decoded for you.
This does not play well with oz when trying to calculate if the file received was the right content length. We write out the response from the requests library to a file and then we check that the file size matches the content length from the http header. If it doesn't match, we move on to trying to boot from a boot.iso, which also doesn't work for aarch64.
You can see this in action here:
In [1]: import requests
@
In [2]: import logging
@
In [3]: logging.basicConfig(level=logging.DEBUG)
@
In [4]: r = requests.get('https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170521.n.0/compose/Everything/aarch64/os/images/pxeboot/vmlinuz')
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): kojipkgs.fedoraproject.org
DEBUG:requests.packages.urllib3.connectionpool:"GET /compose/branched/Fedora-26-20170521.n.0/compose/Everything/aarch64/os/images/pxeboot/vmlinuz HTTP/1.1" 200 6529431
@
In [5]: print r.headers
{'AppTime': 'D=157078', 'Content-Length': '6529431', 'AppServer': 'proxy01.phx2.fedoraproject.org', 'Accept-Ranges': 'bytes', 'Strict-Transport-Security': 'max-age=15768000; includeSubDomains; preload, max-age=15768000; includeSubDomains; preload', 'Keep-Alive': 'timeout=15, max=500', 'Server': 'Apache/2.4.25 (Fedora)', 'Last-Modified': 'Tue, 09 May 2017 16:00:17 GMT', 'Connection': 'Keep-Alive', 'Date': 'Mon, 22 May 2017 14:53:49 GMT', 'Content-Type': 'application/octet-stream', 'Content-Encoding': 'gzip'}
@
In [6]: print len(r.content)
15618560
@
So the Content-Length=6529431, but the actual content is decompressed and of length 15618560.
Why haven't we seen this before?
When dealing with x86_64 kernels, they don't have 'Content-Type': 'application/octet-stream', 'Content-Encoding': 'gzip' headers, which means the requests library doesn't decode them by default:
In [7]: z = requests.get('https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170521.n.0/compose/Everything/x86_64/os/images/pxeboot/vmlinuz')
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): kojipkgs.fedoraproject.org
DEBUG:requests.packages.urllib3.connectionpool:"GET /compose/branched/Fedora-26-20170521.n.0/compose/Everything/x86_64/os/images/pxeboot/vmlinuz HTTP/1.1" 200 7282776
@
In [8]: print z.headers
{'AppTime': 'D=152859', 'Content-Length': '7282776', 'AppServer': 'proxy10.phx2.fedoraproject.org', 'Accept-Ranges': 'bytes', 'Strict-Transport-Security': 'max-age=15768000; includeSubDomains; preload, max-age=15768000; includeSubDomains; preload', 'Keep-Alive': 'timeout=15, max=500', 'Server': 'Apache/2.4.25 (Fedora)', 'Last-Modified': 'Tue, 09 May 2017 15:43:13 GMT', 'Connection': 'Keep-Alive', 'Date': 'Mon, 22 May 2017 14:56:58 GMT'}
@
In [9]: print len(z.content)
7282776
@
This is because the kernel files themselves are different formats so the server is handling them differently:
+[dustymabe@media ~]$ file x86_64-kernel
x86_64-kernel: Linux kernel x86 boot executable bzImage, version 4.11.0-2.fc26.x86_64 ([email protected]) #1 SMP Tue May 9 15:24:49 UTC, RO-rootFS, swap_dev 0x6, Normal VGA
+[dustymabe@media ~]$ file aarch64-kernel
aarch64-kernel: gzip compressed data, max compression, from Unix
The text was updated successfully, but these errors were encountered:
By not setting Accept-Encoding, servers will send Content-Type: x-gzip, which prevents
urllib3 (on behalf of requests) from decompressing it.
Fixes: clalancette#237
Signed-off-by: Patrick Uiterwijk <[email protected]>
By not setting Accept-Encoding, servers will send Content-Type: x-gzip, which prevents
urllib3 (on behalf of requests) from decompressing it.
Fixes: #237
Signed-off-by: Patrick Uiterwijk <[email protected]>
We recently switched to the requests library in oz. This works fine for the most part but the requests library has an interesting (and mostly useful) feature where
The gzip and deflate transfer-encodings are automatically decoded for you.
This does not play well with oz when trying to calculate if the file received was the right content length. We write out the response from the requests library to a file and then we check that the file size matches the content length from the http header. If it doesn't match, we move on to trying to boot from a
boot.iso
, which also doesn't work for aarch64.You can see this in action here:
So the
Content-Length
=6529431
, but the actual content is decompressed and of length15618560
.Why haven't we seen this before?
When dealing with x86_64 kernels, they don't have
'Content-Type': 'application/octet-stream', 'Content-Encoding': 'gzip'
headers, which means the requests library doesn't decode them by default:This is because the kernel files themselves are different formats so the server is handling them differently:
The text was updated successfully, but these errors were encountered: