Arvados

Is ce8i5-4zz18-tnb40vgk9em05h4 readable using the same token? I'm not sure what behavior you were expecting here...

Tom Clegg wrote:

Is ce8i5-4zz18-tnb40vgk9em05h4 readable using the same token? I'm not sure what behavior you were expecting here...

Yes, it is readable by that token.

I was expecting successful PROPFIND response, or an error being logged to explain what aspect of the configuration is preventing it from returning a response.

This works:

curl -v -X PROPFIND https://collections.ce8i5.arvadosapi.com/c=ce8i5-4zz18-tnb40vgk9em05h4/t=zzzzzzzzzzzzzzzzzzzzzzzzzzzzz

This doesn't work:

curl -v -H "Authorization: Bearer zzzzzzzzzzzzzzzzzzzzzzzzzzzzz" -X PROPFIND https://collections.ce8i5.arvadosapi.com/c=ce8i5-4zz18-tnb40vgk9em05h4

This works:

curl -v -H "Authorization: Bearer zzzzzzzzzzzzzzzzzzzzzzzzzzzzz" -X PROPFIND https://download.ce8i5.arvadosapi.com/c=ce8i5-4zz18-tnb40vgk9em05h4

Since these are different virtual hosts of the same keep-web instance, this seems related to the security policies of WebDAV vs WebDAVDownload endpoints.

This is with the following services configuration:

      WebDAV:
        ExternalURL: https://collections.ce8i5.arvadosapi.com/
        InternalURLs:
          "http://localhost:9002": {}
      WebDAVDownload:
        ExternalURL: https://download.ce8i5.arvadosapi.com

The docs say "if you don't have a wildcard DNS entry, then just use https://collections.* and https://download.* as WebDAV and WebDAVDownload URLs; keep-web will treat both as downloads."

In reality, with this config, keep-web doesn't force a download -- it just ignores your credentials (so it only serves anonymously-accessible content) at https://collections.*. This seems like a useful behavior so I'm thinking we should fix the documentation to match the behavior (and make WB2 aware of it), rather than change the behavior to match the docs. Or, a third "inline content, but no auth" endpoint might be better -- that way the config you have now could be flagged as an error, which would be much more sysadmin-friendly.

If you don't configure a WebDAV (non-download) URL at all, Workbench1 does the right thing: it always links to the WebDAVDownload URL, and indicates to the user that preview isn't possible.

I think you get the behavior described in the docs ("everything is a download") if you use the same ExternalURL for both WebDAV and WebDAVDownload, although a WB1 user might be surprised that both "preview" and "download" links result in a download.

IDK whether WB2 tries to predict whether preview is possible.