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
Downloading: https://s3.amazonaws.com/github-cloud/releases/20107688/bd83b39a-f8d8-11e3-9f07-c5afa11724a9.zip?response-content-disposition=attachment%3B%20filename%3Ddav.zip&AWSAccessKeyId=AKIAISTNZFOVBIJMK3TQ&Expires=1403312939&Signature=E4eeWhBREYflaZdxaefBRnBXZQo%3D
Error: ENOENT, no such file or directory '/tmp/temp-dav-1403312878895-1/download/dav.js'
Interestingly, volo's archive lib does a HEAD request on https://github.com/gaye/dav/releases/download/v1.0.3/dav.zip then gets redirected to the s3 url. Then it does a HEAD on the s3 url and s3 responds (wrongly) that the content-type for the zipball is application/xml. Then volo gets confused here
and thinks that what I'm trying to download is not an archive. I think that there's an issue with s3's HEAD implementation, but I wonder if it would be reasonable to patch volo to handle cases in which things that really are zipballs get served up by web servers which don't set application/zip correctly.
On first look, using an manual HTTP send/receive tool, a GET for the Location provided in the 302, Amazon returns an error, which is why the content type is XML:
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>
[more XML goop here]
So I am trying to figure out why the URL generated from GitHub is not good on its own, or if I need to send something else or re-encode something. However, my understanding is that Location URLs should just be sent as-is. The location is on a different domain so I do not think it is about sending a cookie with the request either.
Looks like the HTTP tool I was using was double URL-encoding the query string, so the bug is likely similar in volo. Should have a fix later today or tomorrow.
Looks like it was just the HEAD instead of GET request that the signed AWS URLs do not like, so I just went a GET path for those URLs. Tagged and released on npm as version 0.3.3.
I am trying to do
volo add https://github.com/gaye/dav/releases/download/v1.0.3/dav.zip#dav.js
which fails with
Interestingly, volo's archive lib does a HEAD request on https://github.com/gaye/dav/releases/download/v1.0.3/dav.zip then gets redirected to the s3 url. Then it does a HEAD on the s3 url and s3 responds (wrongly) that the content-type for the zipball is
application/xml
. Then volo gets confused herevolo/lib/archive.js
Line 125 in db7d0f6
and thinks that what I'm trying to download is not an archive. I think that there's an issue with s3's HEAD implementation, but I wonder if it would be reasonable to patch volo to handle cases in which things that really are zipballs get served up by web servers which don't set
application/zip
correctly.Thoughts @jrburke? @millermedeiros?
The text was updated successfully, but these errors were encountered: