GH PDF Download Fails in Zinc, Works with curl

[seandenigris]

The following fails with a 401 error:

'https://github.com/SquareBracketAssociates/Booklet-DataFrame/releases/download/continuous/DataFrame-wip.pdf' asUrl saveContentsToFile: file.

But this works:

curl -Lo wip.pdf  https://github.com/SquareBracketAssociates/Booklet-DataFrame/releases/download/continuous/DataFrame-wip.pdf

NB it too fails without the -L. It downloads something but it is not a valid PDF

[svenvc]

Try:

ZnOptions globalDefault clone
  at: #queryKeyValueSafeSet put: (ZnOptions queryKeyValueSafeSet \ '/;');
  during: [ 'https://github.com/SquareBracketAssociates/Booklet-DataFrame/releases/download/continuous/DataFrame-wip.pdf' asUrl saveContentsToFile: '/tmp/foo.pdf' ].

See #69

[seandenigris]

Thanks! I'm on GT, which has an older version of zinc. I asked on their Discord if they will update. Otherwise, I will try to update manually and report back...

[seandenigris]

Thanks again. GT updated to latest Zinc on 3/3/2022 (per Discord) so I should be all set :)

[Rinzwind]

It’s maybe worth noting here the following two points from RFC 3986:

• Section ‘2.2 Reserved Characters’: “URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent”
• Section ‘2.3 Unreserved Characters’: “URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent”

Semicolon (;) is reserved, tilde (~) is unreserved. So:

• https://example.com/?; and https://example.com/?%3B are not equivalent
• https://example.com/?~ and https://example.com/?%7E are equivalent

The way I understand this in the context of this issue is:

• When I get a redirect to https://example.com/?%3B, but instead request https://example.com/?;: the server is allowed (but not required) to treat that as a different request than one using the URL that it gave me.
• When I get a redirect to https://example.com/?%7E, but instead request https://example.com/?~: the server is required to treat that as the same request as one using the URL that it gave me.