Bug #15936
closed[keep-web] document single-origin collections behavior
Description
Workbench2 is making a PROPFIND request which is failing, here's the keep-web log:
{ "RequestID": "req-z655yiv6e6hz5wx8ey5s", "level": "info", "msg": "response", "remoteAddr": "127.0.0.1:36912", "reqBytes": 0, "reqForwardedFor": "108.7.59.164", "reqHost": "collections.ce8i5.arvadosapi.com", "reqMethod": "PROPFIND", "reqPath": "c=ce8i5-4zz18-tnb40vgk9em05h4", "reqQuery": "", "respBody": "", "respBytes": 0, "respStatus": "Not Found", "respStatusCode": 404, "time": "2019-12-16T20:49:20.099508402Z", "timeToStatus": 0.013435, "timeTotal": 0.01344, "timeWriteBody": 5e-06 }
Updated by Peter Amstutz almost 5 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz almost 5 years ago
- Target version changed from 2020-01-02 Sprint to 2020-01-15 Sprint
Updated by Peter Amstutz almost 5 years ago
- Status changed from In Progress to New
- Description updated (diff)
Updated by Tom Clegg almost 5 years ago
Is ce8i5-4zz18-tnb40vgk9em05h4 readable using the same token? I'm not sure what behavior you were expecting here...
Updated by Peter Amstutz almost 5 years ago
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
Updated by Tom Clegg almost 5 years ago
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.
Updated by Peter Amstutz almost 5 years ago
- Target version changed from 2020-01-15 Sprint to 2020-01-02 Sprint
- Status changed from New to In Progress
- Subject changed from keep-web PROPFIND 404 to [keep-web] document single-origin collections behavior
Updated by Peter Amstutz almost 5 years ago
- Assigned To set to Peter Amstutz
- Subject changed from [keep-web] document single-origin collections behavior to [keep-web] document single-origin collections behavior
Updated by Peter Amstutz almost 5 years ago
- Status changed from In Progress to Resolved