FHIR / sample-ig

A sample, template-driven implementation guide that provides instruction on creating IGs
Other
42 stars 65 forks source link

Follow 302 redirects with curl #35

Closed barabo closed 4 years ago

barabo commented 4 years ago

I noticed that, after running this script, the jar file was only 144 bytes.

Running the commented-out wget command worked for me:

wget https://github.com/HL7/fhir-ig-publisher/releases/latest/download/publisher.jar

So I re-ran the curl command with -v and noticed that the first response was a 302 redirect:

curl -v https://github.com/HL7/fhir-ig-publisher/releases/latest/download/publisher.jar -o ./input-cache/org.hl7.fhir.publisher.jar --create-dirs
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 140.82.114.3...
* TCP_NODELAY set
* Connected to github.com (140.82.114.3) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [216 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2971 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
*  start date: May  5 00:00:00 2020 GMT
*  expire date: May 10 12:00:00 2022 GMT
*  subjectAltName: host "github.com" matched cert's "github.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
> GET /HL7/fhir-ig-publisher/releases/latest/download/publisher.jar HTTP/1.1
> Host: github.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found
< server: GitHub.com
< date: Wed, 01 Jul 2020 21:29:41 GMT
< content-type: text/html; charset=utf-8
< status: 302 Found
< vary: X-PJAX, Accept-Encoding, Accept, X-Requested-With
< location: https://github.com/HL7/fhir-ig-publisher/releases/download/1.1.0/publisher.jar
< cache-control: no-cache
...

It seemed that curl needs an extra nudge to follow redirects. Looking in the man page I found -L, which worked for me:

       -L, --location
              (HTTP)  If  the server reports that the requested page has moved
              to a different location (indicated with a Location: header and a
              3XX  response code), this option will make curl redo the request
              on the new place. If used together with  -i,  --include  or  -I,
              --head,  headers  from  all  requested pages will be shown. When
              authentication is used, curl only sends its credentials  to  the
              initial  host.  If a redirect takes curl to a different host, it
              won't be able to intercept the user+password. See  also  --loca-
              tion-trusted  on how to change this. You can limit the amount of
              redirects to follow by using the --max-redirs option.