HEAD against dandiarchive webdav service results in 403

[bbockelm]

I've been working to utilize #166 with OSDF using Pelican. However, when I issue a HTTP HEAD request (for various reasons, we want to see the content length prior to pulling the object), I ultimately get a 403.

To reproduce, try the following curl command:

curl -L -I -v https://webdav.dandiarchive.org/dandisets/000004/latest/sub-P10HMH/sub-P10HMH_ses-20060901_ecephys+image.nwb

Currently, this results in the following redirections:

1. https://webdav.dandiarchive.org/dandisets/000004/latest/sub-P10HMH/sub-P10HMH_ses-20060901_ecephys+image.nwb ->
2. https://api.dandiarchive.org/api/assets/38304fe9-5f37-4c0d-a741-9cf2bafab9ff/download/ ->
3. https://dandiarchive.s3.amazonaws.com/blobs/284/eb3/284eb346-0bc5-42a6-9b33-268e6b0b0bde?response-content-disposition=attachment%3B%20filename%3D%22sub-P10HMH_ses-20060901_ecephys%2Bimage.nwb%22&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAUBRWC5GAEKH3223E%2F20240316%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20240316T211441Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=REDACTED

If I swap out the HEAD with a GET, it appears I can download the file normally.

It's surprisingly non-trivial to get rid of the HEAD request from my side: can we fix the AWS permission? Alternately, if api.dandiarchive.org knows the size of the file, the redirect can probably be skipped.