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
Given an attachment with a forward slash in the name, SG will not handle the route correctly. Instead, the route matching should not be greedy with respect to /, and instead stop caring about / once it has a dbname,doc-id tuple.
For example, the following fail, but would be expected to work (as they do for local docs).
Given:
This feature is already supported, but with the following caveats.
When both file names and attachment names contain '/' characters, there is no obvious way to determine the boundary between the file name and attachment name.
SG handles this by requiring embedded slashes to be escaped using URL encoding ('%2F') in all requests.
e.g. the following steps work:
curl -X PUT http://localhost:4985/db/doca -H "Content-Type: application/json" -d '{"foo":"bar"}'
curl -vX PUT http://localhost:4985/db/doca/attachments%2F50k.png?rev=2-24bfd66d8c0b8a150e12deefd4a06edf --data-binary @50k.png -H "Content-Type: image/png"
curl -vX GET http://localhost:4985/db/doca/attachments%2F50k.png > /dev/null
Additional unit tests have been added to ensure this behaviour does not regress.
Given an attachment with a forward slash in the name, SG will not handle the route correctly. Instead, the route matching should not be greedy with respect to
/
, and instead stop caring about/
once it has adbname,doc-id
tuple.For example, the following fail, but would be expected to work (as they do for local docs).
Given:
I expect this to return '201':
And I expect this command to return the
.js
file that I previouslyPUT
.The text was updated successfully, but these errors were encountered: