openSUSE admin

Wireshark shows the connection was cleanly closed by the server (FIN+ACK, FIN+ACK, ACK). It happens with and without TLS, with HTTP/1 as well as HTTP/2. How much data is downloaded changes on every try.

Since download.o.o doesn't actually serve big files - it is important to note to which actual url did redirect happen. Is it possible to increase verbosity of log in openQA?
(I tried the same from heroes network: first to check headers and was redirected to downloadcontent2.o.o (which happens when no mirrors are available), but then started download and was redirected to ftp.gwdg.de and download successfully completed in 15 sec.)

andriinikitin wrote:

Since download.o.o doesn't actually serve big files - it is important to note to which actual url did redirect happen. Is it possible to increase verbosity of log in openQA?
(I tried the same from heroes network: first to check headers and was redirected to downloadcontent2.o.o (which happens when no mirrors are available), but then started download and was redirected to ftp.gwdg.de and download successfully completed in 15 sec.)

In all cases here the actual download was via http://downloadcontent2.opensuse.org/repositories/GNOME:/Medias/images/iso/GNOME_Next.x86_64-43.1-Build22.189.iso.

It might be that the varnish cache there has trouble with such large files. Is there a way for MirrorCache to still redirect these to downloadcontent.o.o ?

I'm now redirecting .iso, .raw.xz, .qcow2, etc files to downloadcontent.o.o via varnish
= https://github.com/bmwiedemann/varnishcontainer/commit/a32a6c002ee

http://lists.varnish-cache.org/pipermail/varnish-misc/2016-April/024903.html

Apparently varnish might decide not to cache the file while it's being streamed and then just closes the connection shrug