Message6752
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? |
|
Date |
User |
Action |
Args |
2019-10-17 14:50:58 | rouilj | set | recipients:
+ rouilj, schlatterbeck |
2019-10-17 14:50:58 | rouilj | link | issue2551067 messages |
2019-10-17 14:50:58 | rouilj | create | |
|