Installer freezes in windows-2022 GitHub Action

[Brian Inglis]

On 2024-10-21 11:36, Michele Locati via Cygwin wrote:
> Il giorno lun 21 ott 2024 alle ore 19:03 Brian Inglis via Cygwin
> <cygwin@cygwin.com> ha scritto:
>>> I think it was probably an issue caused by a malformed executable in a
>>> mirror/CDN (which would explain why it worked sometimes and sometimes
>>> not).
>>
>> That's kind of worrying, but also kind of typical of MS service expectations ;^>
> 
> The problem still persists: there's really something wrong in the
> distribution of the installer...
> 
> Try running this posix script (I just tried it on a bare metal linux machine):
> 
> 
> #!/bin/sh
> set -o errexit
> set -o nounset
> url=https://cygwin.com/setup-x86_64.exe
> printf 'Downloading %s multiple times (press Ctrl+C to stop)\n' "$url"
> while :; do
>      printf 'Downloading... '
>      size=$(curl -s -o /dev/null -w '%{size_download}' "$url")
>      printf 'done: %s bytes\n' $size
>      sleep 1
> done
> 
> 
> Here's what I get:
> 
> Downloading https://cygwin.com/setup-x86_64.exe multiple times (press
> Ctrl+C to stop)
> Downloading... done: 1407507 bytes
> Downloading... done: 1407507 bytes
> Downloading... done: 0 bytes
> Downloading... done: 0 bytes
> Downloading... done: 0 bytes
> Downloading... done: 0 bytes
> Downloading... done: 0 bytes
> Downloading... ^C

I get similar results, but a proxy and/or CDN is upstream: see below for my 
opinions about some of this.

> So, unless the file is served by a Microsoft service, I don't think MS
> has anything to do with this issue...
> 
> Maybe there's some sort of protection from downloading the installer
> multiple times from the same IP?
> That would break big companies (who may have many PC internally but
> just 1 public IP), as well as services like GitHub Actions (which may
> have just a few of public IPs)....

Modern networks and utilities can deal appropriately with NATs.

> That's really something that should be fixed...

I typically use wget -N -nv for downloads, without any issues for decades, on 
any service.

These urls say do not cache:

$ curl -I https://cygwin.com/setup-x86_64.exe{,.sig}
HTTP/2 200
date: Mon, 21 Oct 2024 17:41:25 GMT
server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_qos/11.74 
mod_wsgi/4.6.4 Python/3.6 mod_perl/2.0.12 Perl/v5.26.3
vary: User-Agent
last-modified: Tue, 16 Apr 2024 18:39:28 GMT
etag: "236-6163b0ed908ba"
accept-ranges: bytes
content-length: 566
cache-control: max-age=0
expires: Mon, 21 Oct 2024 17:41:25 GMT
content-security-policy: default-src 'self' http: https:
strict-transport-security: max-age=16070400
x-cache: MISS from cygwin.com
content-type: application/pgp-signature

HTTP/2 200
date: Mon, 21 Oct 2024 17:41:25 GMT
server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_qos/11.74 
mod_wsgi/4.6.4 Python/3.6 mod_perl/2.0.12 Perl/v5.26.3
vary: User-Agent
last-modified: Tue, 16 Apr 2024 18:39:04 GMT
etag: "157a13-6163b0d6e8405"
accept-ranges: bytes
content-length: 1407507
cache-control: max-age=0
expires: Mon, 21 Oct 2024 17:41:25 GMT
content-security-policy: default-src 'self' http: https:
strict-transport-security: max-age=16070400
x-cache: MISS from cygwin.com
content-type: application/octet-stream

Note:
CDNs use proxies and add X-... headers to results:
X-Cache-Lookup	proxy has cache-able resource	HIT yes, MISS no
X-Cache		proxy result served from cache	HIT yes, MISS no

If those headers are ignored by GitHub or their or your upstream, or an 
intermediate proxy, or they have *policies*, or they or you have an AntiVirus 
product, who knows what happens?

As this infrastructure is shared by other sourceware.org projects, and we have 
not heard anything else, it may be a problem nearer yourself.
If you have networking support, ask them why you get nothing from a request?

Also note the response cache hint "vary: User-Agent" allowing the CDN/proxy 
cache to make assumptions about how different user agents will handle requests: 
in the case of requests from command line clients, they can perhaps assume that 
the previously downloaded file will be left intact if nothing is provided.

Remember that these are really browser queries and it is not a problem for the 
CDN/proxy cache if the client does not actually have a local cache from which 
they can serve the file: the previously downloaded copy may have to be handled 
as if it is a cached copy.

Also, you can run curl as if it were like wget using such options as:

	-R, --remote-time
	-Z, --parallel
	-z, --time-cond TIME|FILE
also
	--etag-save 	FILE
	--etag-compare	FILE

similar to cookies.

And Cygwin curl is packaged with easy front end wcurl which works like wget 
using curl and a bunch of useful assumptions about downloading to set 
appropriate options.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry