Hi Ralf:

In message <20191017095339.nx5hhxgxu4wtzxs7@runtux.com>,
Ralf Schlatterbeck writes:
>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

Hmm, I'll check tonight to make sure I included the terminating /.  I
am sure I cut/pasted it, but I may have dropped the /.

>> 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?

IIRC it's implemented in the db.

>Or is this something in the web server used?

I'm using roundup-server.

>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.

If you hex encode all non-utf-8 characters. \\x00 is a null with
an escaped initial \ right? Which I think is correct for 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 assume you mean yes there should be a way to download binary data
via /rest path.

>> I think the right way to do this is to make the request to
>> demo/rest/data/file/11/content but set the header:

       ^  corrected added /rest.

>> 
>>  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?

If I don't set an accept header, I will get back a json wrapped blob
of data. Hitting /content wil return a json { data: {link:
..., data: ..., @etag: ...}} object.

If I set the accept to something that does not allow json, I can
return something of that type (the raw content data) or say I can't
accomidate your request (406 error).

Does that make it clearer?