On Wed, Oct 16, 2019 at 11:53:43PM +0000, John Rouillard wrote:
> but I can't actually use https://.../demo/file11/ to get the contents
> of the file.

Really? The trailing '/' makes the difference for me.
So roundup really doesn't care if a filename follows, the two URLs (last
time I looked):
https://.../demo/file11/
https://.../demo/file11/afile

Both yield the file contents while the URL without the '/' yields the
file edit page:

https://.../demo/file11

This might have changed in the meantime. BTW, you could append *anything*
after the '/', all would yield the content, e.g.,

https://.../demo/file11/justarandomstring

> That returns the full file11 page including page.html and the form to
> change the file's metadata. To get the file contents, I need to use:
> 
>    https://.../demo/file11/afile
> 
> should we change that response? Currently, you need to get
> demo/data/file/11, pull the name and append it to the content link.

See above, the trailing '/' makes the difference for me, after the '/'
anything can follow.

> Also if I get demo/data/file/11/content, I see:
> 
>       "data": "file11 is not text, retrieve using binary_content property. mdsum: bd990c0f8833dd991daf610b81b62316",
> 
> but using demo/data/file/11/binary_content I get:
> 
>   "data": "b'\\x00\\x00\\x01\\x00\\x01\\x00\\x10\\x10\\x00\\x00\\x00\\x00\\x00\\x00h\\x05\\x00\\x00\\x16\\x00\\x00\\x00(\\x00\\x1c\\x1c\\x1c\\x00ttt ...
> 
> etc.  It is encapsulated in the json data wrapper. I assume that is
> some encoded form of actual binary data? Is that encoded form
> decodable from javascript?

I've never seen 'binary_content', did someone implement this? Or is this
something in the web server used? And I don't think this can be decoded
in javascript because js expects UTF-8. So no arbitrary binary data can
be encoded in JSON.

> Given how this bloats the file size, I wonder if we should provide a
> way via the rest interface to download just the content data in raw
> form.
Yes, I don't think it makes much sense. And I don't think javascript
could parse it for arbitrary binary data.

> I think the right way to do this is to make the request to
> demo/data/file/11/content but set the header:
> 
>  Accept:  image/vnd.microsoft.icon
> 
> If the content type matches the file type, respond with a binary data
> stream with appropriate Content-Type (either the same as the Accept
> type or application/octet-stream) and Content-Length. If it doesn't
> match we return 406 - not acceptable.

I don't get the part with the 'image/vnd.microsoft.icon' content-type.
Why do you do this?

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com