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
When downloading from a url with et.data.get_data(), there is a bug where the file will not be named correctly occasionally. For example, when downloading from https://ndownloader.figshare.com/files/12767966, we would expect the file name to be boulder-temp-2017.txt, however it currently returns a file with the right data in it, but named 12767966 with no extension. This is due to the code looking for a keyword in the header returned from the request. It can't find the keyword even though the download was successful, so it defaults to the last part of the url. Worth noting, the keyword it's looking for exists if the code uses requests.get instead of requests.head in this one case at least. Not sure if that's consistent. Seems to be that maybe a recent update requests changed the name of the headers returned, but not sure!
The text was updated successfully, but these errors were encountered:
confirmed i am also getting this same response and i tested on requests version 2.25.1 and 2.26 on a MAC. Nathan also mentioned that we could ensure this fails a bit more gracefully in the future so it's worth looking into that as well. this could be due to an update to the requests module if it's working on some machines but not others.
When downloading from a
url
withet.data.get_data()
, there is a bug where the file will not be named correctly occasionally. For example, when downloading fromhttps://ndownloader.figshare.com/files/12767966
, we would expect the file name to beboulder-temp-2017.txt
, however it currently returns a file with the right data in it, but named12767966
with no extension. This is due to the code looking for a keyword in the header returned from the request. It can't find the keyword even though the download was successful, so it defaults to the last part of the url. Worth noting, the keyword it's looking for exists if the code usesrequests.get
instead ofrequests.head
in this one case at least. Not sure if that's consistent. Seems to be that maybe a recent update requests changed the name of the headers returned, but not sure!The text was updated successfully, but these errors were encountered: