Bug 857838 - VM payload should accept arbitrary binary input
VM payload should accept arbitrary binary input
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.1.0
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: nobody nobody
Tareq Alayan
virt
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-17 03:57 EDT by Geert Jansen
Modified: 2013-07-11 17:24 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-11 17:24:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Geert Jansen 2012-09-17 03:57:58 EDT
Currently the VM payload feature is restricted in the input it accepts. I haven't tested the full range of characters that it might accept, but so far my testing has found this:

 * Newlines are not accepted.
 * XML unsafe characters like '<' and '>' are not accepted as they result in the input XML being not well formed and rejected at the RESTeasy level.

As a design goal, we should make sure we support a wide array of applications with VM payload. This means that we should have as little limitations on the payload data as possible.

I propose that the API accepts the VM payload in an encoded format that is safe to embed in XML. The most common format seems to be base64.

At some point before the payload is provided to the VM, should be decoded. This decoding can be done where ever makes sense (API, engine, VDSM). The goal is that a user is able to provide a binary blob as payload containing the full range of  byte values (0 .. 255) up to the length limit for VM payloads.

Below i've added an example that  shows that the API currently does not accept multi-line input:

# cat update.xml
<vm>
  <payloads>
    <payload type="floppy">
      <file name="payload.txt">
<content>line one
line two
line three
</content>
      </file>
    </payload>
  </payloads>
</vm>

Using this cURL command:

# curl -k --user admin@internal:xxxx --request PUT --data @update.xml --header "Content-Type: application/xml" https://localhost:443/api/vms/{id}

What i get back is this:

    <payloads>
        <payload type="floppy">
            <file name="payload.txt">
                <content>line oneline twoline three</content>
            </file>
        </payload>
    </payloads>

So the content is now all on 1 line. And when i mount the floppy in the guest, i see the same thing (newlines removed).
Comment 1 Geert Jansen 2012-09-17 07:45:49 EDT
This is not a FutureFeature.
Comment 2 Andrew Cathrow 2012-09-17 09:05:23 EDT
We should accept any content in the payload.

Michael - what's the scope of effort to fix this?
Comment 3 Itamar Heim 2012-09-17 11:47:27 EDT
michael/shahar - don't we support base64 encoded content?
Comment 4 Yaniv Kaul 2012-09-18 16:32:50 EDT
(In reply to comment #2)
> We should accept any content in the payload.

According to http://wiki.ovirt.org/wiki/Features/VMPayload : "The payload data will be encoded using base64 encoding", so we don't accept *any* type - unless we have some encoding mechanism.

QE conditional NACK on requirements.

> 
> Michael - what's the scope of effort to fix this?
Comment 5 Michael Pasternak 2012-09-19 02:20:40 EDT
Hi Geert,

I had no problem passing multilined <content> using [1], i think the problem
is in the client you have used.

[1]

<vm>
  <payloads>
    <payload type="floppy">
      <file name="payload.txt">
        <content>
          content here1
          content here2
          content here3
        </content>
      </file>
    </payload>
  </payloads>
</vm>
Comment 6 Michael Pasternak 2012-09-19 02:44:46 EDT
(In reply to comment #4)
> (In reply to comment #2)
> > We should accept any content in the payload.
> 
> According to http://wiki.ovirt.org/wiki/Features/VMPayload : "The payload
> data will be encoded using base64 encoding", so we don't accept *any* type -
> unless we have some encoding mechanism.

if there any "encoding mechanism" it's resides in BE, (api is agnostic to data formats and /get on payload returns plain text), Shahar?

> 
> QE conditional NACK on requirements.
> 
> > 
> > Michael - what's the scope of effort to fix this?
Comment 7 Shahar Havivi 2012-09-23 05:42:53 EDT
The VmPayload current design is support only text files.
The engine is getting a plain text and encode it to Base64 before storing the data in DB.
Geert, I think Michael is right, you can try use cdata tag as your content wrapper: http://www.w3schools.com/xml/xml_cdata.asp
Comment 9 Itamar Heim 2012-10-01 09:17:33 EDT
please re-open if can be reproduced per above comments.
Comment 10 Geert Jansen 2012-10-16 12:38:04 EDT
I tried CDATA but it gave a RESTeasy error. But in any case, you cannot pass arbitrary binary data in CDATA so the point is moot.

Why is this closed by the way? It was already moved to rhevm-future and if it is closed we would not be able to find it anymore.
Comment 11 Itamar Heim 2012-10-17 01:36:17 EDT
bugs with needinfo for too long are closed insufficent data asking to re-open if can be reproduced.
Comment 12 Itamar Heim 2012-10-17 01:37:19 EDT
michael, per your comment 5, can you please put a sample of updating multi line content and getting it back as multiline?

thanks,
  Itamar
Comment 13 Michael Pasternak 2012-10-17 04:27:16 EDT
(In reply to comment #12)
> michael, per your comment 5, can you please put a sample of updating multi
> line content and getting it back as multiline?
> 
> thanks,
>   Itamar


* using FF REST extension

vm before
=========
GET http://localhost:8080/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76

<vm id="f409c734-65f2-4d7c-b25b-3e285d8d5a76" href="/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76">
    <name>iscsi_desktop</name>
    <type>desktop</type>
    <status>
        <state>down</state>
    </status>
    ...
</vm>

request
=======
PUT http://localhost:8080/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76

<vm>
  <payloads>
    <payload type="floppy">
      <file name="payload.txt">
        <content>
          content here1
          content here2
          content here3
        </content>
      </file>
    </payload>
  </payloads>
</vm>

vm after
========
GET http://localhost:8080/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vm id="f409c734-65f2-4d7c-b25b-3e285d8d5a76" href="/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76">
    <name>iscsi_desktop</name>
    <type>desktop</type>
    <status>
        <state>down</state>
    </status>
    ...
    <payloads>
        <payload type="floppy">
            <file name="payload.txt">
                <content>
          content here1
          content here2
          content here3
                </content>
            </file>
        </payload>
    </payloads>
    ...
</vm>
Comment 14 Itamar Heim 2012-10-17 04:34:04 EDT
geert - please review comment 13
Comment 15 Geert Jansen 2012-10-17 06:02:22 EDT
Regarding comment 13, multi-line input may work now, but this BZ is about accepting *binary* input for the vmpayload feature.

Even using CDATA, you cannot pass binary input.
Comment 16 Michael Pasternak 2012-10-17 08:17:13 EDT
(In reply to comment #15)
> Regarding comment 13, multi-line input may work now, but this BZ is about
> accepting *binary* input for the vmpayload feature.
> 
> Even using CDATA, you cannot pass binary input.

WORKS-FOR-ME (Geert, i think the problem is in your client):

request:
=======
PUT http://localhost:8080/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76

<vm>
  <payloads>
    <payload type="floppy">
      <file name="payload.txt">
        <content>
<![CDATA[
^?ELF^B^A^A^@^@^@^@^@^@^@^@^@^B^@>^@^A^@^@^@<D0>^_@^@^@^@^@^@@^@^@^@^@^@^@^@<U+0620>^@^@^@^@^@^@^@^@^@^@@^@8^@^H^@@^@^_^@^^^@^F^@^@^@^E^@^@^@@^@^@^@^@^@^@^@@^@
@^@^@^@^@^@@^@@^@^@^@^@^@<C0>^A^@^@^@^@^@^@<C0>^A^@^@^@^@^@^@^H^@^@^@^@^@^@^@^C^@^@^@^D^@^@^@^@^B^@^@^@^@^@^@^@^B@^@^@^@^@^@^@^B@^@^@^@^@^@^\^@^@^@^@^@^@^@^\^@
^@^@^@^@^@^@^A^@^@^@^@^@^@^@^A^@^@^@^E^@^@^@^@^@^@^@^@^@^@^@^@^@@^@^@^@^@^@^@^@@^@^@^@^@^@><8D>^@^@^@^@^@^@><8D>^@^@^@^@^@^@^@^@ ^@^@^@^@^@^A^@^@^@^F^@^@^@^@
<90>^@^@^@^@^@^@^@<90>`^@^@^@^@^@^@<90>`^@^@^@^@^@<E0>^F^@^@^@^@^@^@<98>8^A^@^@^@^@^@^@^@ ^@^@^@^@^@^B^@^@^@^F^@^@^@(<90>^@^@^@^@^@^@(<90>`^@^@^@^@^@(<90>`^@^@
^@^@^@<A0>^A^@^@^@^@^@^@<A0>^A^@^@^@^@^@^@^H^@^@^@^@^@^@^@^D^@^@^@^D^@^@^@^\^B^@^@^@^@^@^@^\^B@^@^@^@^@^@^\^B@^@^@^@^@^@D^@^@^@^@^@^@^@D^@^@^@^@^@^@^@^D^@^@^@
^@^@^@^@P<E5>td^D^@^@^@<E8><82>^@^@^@^@^@^@<E8><82>@^@^@^@^@^@<E8><82>@^@^@^@^@^@<E4>^@^@^@^@^@^@^@<E4>^@^@^@^@^@^@^@^D^@^@^@^@^@^@^@Q<E5>td^F^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^H^@^@^@^@^@^@^@/lib64/ld-linux-x86-64.so.2^@^D^@^@^@^P^@^@^@^A^@^@^@GNU^@^@^@^@^@^B^@^@
^@^F^@^@^@^R^@^@^@^D^@^@^@^T^@^@^@^C^@^@^@GNU^@o<B8>ղH<92> <DE>n<8A><B1><83><93>,ش[<80><B9>H%^@^@^@@^@^@^@^D^@^@^@^H^@^@^@^B<A1><A0><A0><D1>d^@<82>^Ha^D^P<84>
^Y`<E2><81>^@#<C4>Z<80>^\<A6><80>^@^M`<82>^@)^C@^@^@^@^@^@^@^@A^@^@^@^@^@^@^@B^@^@^@D^@^@^@^@^@^@^@F^@^@^@G^@^@^@I^@^@^@J^@^@^@^@^@^@^@^@^@^@^@M^@^@^@^@^@^@^@O
^@^@^@Q^@^@^@S^@^@^@T^@^@^@^@^@^@^@U^@^@^@V^@^@^@^@^@^@^@W^@^@^@^@^@^@^@^@^@^@^@X^@^@^@Z^@^@^@\^@^@^@^^@^@^@_^@^@^@`^@^@^@b^@^@^@d^@^@^@e^@^@^@f^@^@^@^@^@^@^@
<9F><9F><F7><96><DD><F9>j^X&A<88><95><E7><9E>(;|<E8>a<E9><F9>0s*w<FF>:^\*O4<8C>?<A7><88>^K<D1>^S.^K<BA><D5><ED><81>~<A2><96>2<87><B2><88>^K8<9F><A3>^O<91>P<F0>
q<BE>^Z<99><CC>M<88>s<B3><A4>t<A4><EB>^]^W^R<82>C<F9><AB>1<91><80><9A>|<F5><F3>Q<90><A3>G^N<C6>O<A7><C9>w^T^O<89><F8><DF><E1>-^@l^R<87>¡濰 *s^P^_<88><9E>|]<B5>
<9D>}-^M^_^^<C6>R^_^\<B3><FD>q<D3>^\g^R^O<B9><AF><88>^K/<A4><9E>|c+<B5><DD>^??^ES^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@  ^A^@^@^R^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@'^B^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<CA>^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<FC>^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@d^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Z^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<D0>^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^N^@^@^@
 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^]^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<DE>^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@U^B^@^@^R^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@<83>^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@v^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^B^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@<F4>^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@X^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<9B>^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
]]>
        </content>
      </file>
    </payload>
  </payloads>
</vm>

response:
========
GET http://localhost:8080/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vm id="f409c734-65f2-4d7c-b25b-3e285d8d5a76" href="/api/vms/f409c734-65f2-4d7c-b25b-3e285d8d5a76">
    <name>iscsi_desktop</name>
    <type>desktop</type>
    <status>
        <state>down</state>
    </status>
    <payloads>
        <payload type="floppy">
            <file name="payload.txt">
                <content>

^?ELF^B^A^A^@^@^@^@^@^@^@^@^@^B^@&gt;^@^A^@^@^@&lt;D0&gt;^_@^@^@^@^@^@@^@^@^@^@^@^@^@&lt;U+0620&gt;^@^@^@^@^@^@^@^@^@^@@^@8^@^H^@@^@^_^@^^^@^F^@^@^@^E^@^@^@@^@^@^@^@^@^@^@@^@
@^@^@^@^@^@@^@@^@^@^@^@^@&lt;C0&gt;^A^@^@^@^@^@^@&lt;C0&gt;^A^@^@^@^@^@^@^H^@^@^@^@^@^@^@^C^@^@^@^D^@^@^@^@^B^@^@^@^@^@^@^@^B@^@^@^@^@^@^@^B@^@^@^@^@^@^\^@^@^@^@^@^@^@^\^@
^@^@^@^@^@^@^A^@^@^@^@^@^@^@^A^@^@^@^E^@^@^@^@^@^@^@^@^@^@^@^@^@@^@^@^@^@^@^@^@@^@^@^@^@^@&gt;&lt;8D&gt;^@^@^@^@^@^@&gt;&lt;8D&gt;^@^@^@^@^@^@^@^@ ^@^@^@^@^@^A^@^@^@^F^@^@^@^@
&lt;90&gt;^@^@^@^@^@^@^@&lt;90&gt;`^@^@^@^@^@^@&lt;90&gt;`^@^@^@^@^@&lt;E0&gt;^F^@^@^@^@^@^@&lt;98&gt;8^A^@^@^@^@^@^@^@ ^@^@^@^@^@^B^@^@^@^F^@^@^@(&lt;90&gt;^@^@^@^@^@^@(&lt;90&gt;`^@^@^@^@^@(&lt;90&gt;`^@^@
^@^@^@&lt;A0&gt;^A^@^@^@^@^@^@&lt;A0&gt;^A^@^@^@^@^@^@^H^@^@^@^@^@^@^@^D^@^@^@^D^@^@^@^\^B^@^@^@^@^@^@^\^B@^@^@^@^@^@^\^B@^@^@^@^@^@D^@^@^@^@^@^@^@D^@^@^@^@^@^@^@^D^@^@^@
^@^@^@^@P&lt;E5&gt;td^D^@^@^@&lt;E8&gt;&lt;82&gt;^@^@^@^@^@^@&lt;E8&gt;&lt;82&gt;@^@^@^@^@^@&lt;E8&gt;&lt;82&gt;@^@^@^@^@^@&lt;E4&gt;^@^@^@^@^@^@^@&lt;E4&gt;^@^@^@^@^@^@^@^D^@^@^@^@^@^@^@Q&lt;E5&gt;td^F^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^H^@^@^@^@^@^@^@/lib64/ld-linux-x86-64.so.2^@^D^@^@^@^P^@^@^@^A^@^@^@GNU^@^@^@^@^@^B^@^@
^@^F^@^@^@^R^@^@^@^D^@^@^@^T^@^@^@^C^@^@^@GNU^@o&lt;B8&gt;H&lt;92&gt; &lt;DE&gt;n&lt;8A&gt;&lt;B1&gt;&lt;83&gt;&lt;93&gt;,[&lt;80&gt;&lt;B9&gt;H%^@^@^@@^@^@^@^D^@^@^@^H^@^@^@^B&lt;A1&gt;&lt;A0&gt;&lt;A0&gt;&lt;D1&gt;d^@&lt;82&gt;^Ha^D^P&lt;84&gt;
^Y`&lt;E2&gt;&lt;81&gt;^@#&lt;C4&gt;Z&lt;80&gt;^\&lt;A6&gt;&lt;80&gt;^@^M`&lt;82&gt;^@)^C@^@^@^@^@^@^@^@A^@^@^@^@^@^@^@B^@^@^@D^@^@^@^@^@^@^@F^@^@^@G^@^@^@I^@^@^@J^@^@^@^@^@^@^@^@^@^@^@M^@^@^@^@^@^@^@O
^@^@^@Q^@^@^@S^@^@^@T^@^@^@^@^@^@^@U^@^@^@V^@^@^@^@^@^@^@W^@^@^@^@^@^@^@^@^@^@^@X^@^@^@Z^@^@^@\^@^@^@^^@^@^@_^@^@^@`^@^@^@b^@^@^@d^@^@^@e^@^@^@f^@^@^@^@^@^@^@
&lt;9F&gt;&lt;9F&gt;&lt;F7&gt;&lt;96&gt;&lt;DD&gt;&lt;F9&gt;j^X&amp;A&lt;88&gt;&lt;95&gt;&lt;E7&gt;&lt;9E&gt;(;|&lt;E8&gt;a&lt;E9&gt;&lt;F9&gt;0s*w&lt;FF&gt;:^\*O4&lt;8C&gt;?&lt;A7&gt;&lt;88&gt;^K&lt;D1&gt;^S.^K&lt;BA&gt;&lt;D5&gt;&lt;ED&gt;&lt;81&gt;~&lt;A2&gt;&lt;96&gt;2&lt;87&gt;&lt;B2&gt;&lt;88&gt;^K8&lt;9F&gt;&lt;A3&gt;^O&lt;91&gt;P&lt;F0&gt;
q&lt;BE&gt;^Z&lt;99&gt;&lt;CC&gt;M&lt;88&gt;s&lt;B3&gt;&lt;A4&gt;t&lt;A4&gt;&lt;EB&gt;^]^W^R&lt;82&gt;C&lt;F9&gt;&lt;AB&gt;1&lt;91&gt;&lt;80&gt;&lt;9A&gt;|&lt;F5&gt;&lt;F3&gt;Q&lt;90&gt;&lt;A3&gt;G^N&lt;C6&gt;O&lt;A7&gt;&lt;C9&gt;w^T^O&lt;89&gt;&lt;F8&gt;&lt;DF&gt;&lt;E1&gt;-^@l^R&lt;87&gt; *s^P^_&lt;88&gt;&lt;9E&gt;|]&lt;B5&gt;
&lt;9D&gt;}-^M^_^^&lt;C6&gt;R^_^\&lt;B3&gt;&lt;FD&gt;q&lt;D3&gt;^\g^R^O&lt;B9&gt;&lt;AF&gt;&lt;88&gt;^K/&lt;A4&gt;&lt;9E&gt;|c+&lt;B5&gt;&lt;DD&gt;^??^ES^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@  ^A^@^@^R^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@'^B^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@&lt;CA&gt;^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@&lt;FC&gt;^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@d^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Z^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@&lt;D0&gt;^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^N^@^@^@
 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^]^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@&lt;DE&gt;^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@U^B^@^@^R^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@&lt;83&gt;^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@v^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^B^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@&lt;F4&gt;^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@X^A^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@&lt;9B&gt;^@^@^@^R^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

        </content>
            </file>
        </payload>
    </payloads>
    ...
</vm>
Comment 17 Geert Jansen 2012-10-17 08:41:23 EDT
Michael, please try to upload a file that contains the characters ']]>'. This will not work.

Also, the *output* of the API above, will very likely be invalid XML, unless RESTeasy inserts CDATA on output too.
Comment 18 Michael Pasternak 2012-10-17 09:04:57 EDT
(In reply to comment #17)
> Michael, please try to upload a file that contains the characters ']]>'.
> This will not work.

indeed, - it's explicitly forbidden by spec., workaround will be allowing
file upload via dedicated endpoint rather than using xml element for this.

also it means that we won't be able displaying it.

i guess for now we can state that we support only text files and
binary is a TP.

> 
> Also, the *output* of the API above, will very likely be invalid XML, unless
> RESTeasy inserts CDATA on output too.

this output fetched from my server.
Comment 19 Geert Jansen 2012-10-17 09:14:50 EDT
Can we do this: add a encoding="base64" attribute to <content>, and if set, base64-decode the contents? Should be a few lines of Java code.
Comment 20 Michael Pasternak 2012-10-17 09:31:56 EDT
(In reply to comment #19)
> Can we do this: add a encoding="base64" attribute to <content>, and if set,
> base64-decode the contents? Should be a few lines of Java code.

we can, but it's not so user friendly, now when i'm thinking about this, we modelled entire feature incorrectly,

it was suppose to be sub-collection/resource of vm, this way we would have
/api/vms/xxx/payloads endpoint for uploads (also it adds tone of garbage to
vm representation on GET):

/api/vms/xxx/payloads
  <payloads>
    <payload type="floppy" id=yyy>
      <file name="payload.txt">
        <content>
          ...
        </content>
      </file>
    </payload>
  </payloads>

/api/vms/xxx/payloads/yyy
  <payload type="floppy" id=yyy>
    <file name="payload.txt">
      <content>
        ...
      </content>
    </file>
  </payload>

if we want changing it, the time is now, or we will have to carry this design
for next few versions, andy/simon/itamar/geert?
Comment 21 Geert Jansen 2012-10-17 10:04:48 EDT
Your proposed changes make sense. However, this does not remove the need for base64 encoded <content>.
Comment 22 Michael Pasternak 2012-10-17 10:13:05 EDT
(In reply to comment #21)
> Your proposed changes make sense. However, this does not remove the need for
> base64 encoded <content>.

why? you will be able uploading binary file as-is, without converting
it to text and/or encoding.
Comment 23 Geert Jansen 2012-10-17 10:48:19 EDT
If we keep the logic, then the "payloads" collection will contain <payload> resources that itself are XML and contain a <file> child element with a <content> grandchild element.

Or do you want a "content" sub-resource below the payload resource, i.e "/api/vms/xxx/payloads/yyy/contents"?
Comment 24 Itamar Heim 2012-10-17 18:40:55 EDT
geert - can you explain the use case for binary input? you do remember it is limited to 16KB? it is not intended for binary upload in general?

michael - we don't have an id per payload (other than the file id maybe)?
Comment 25 Michael Pasternak 2012-10-18 02:53:43 EDT
(In reply to comment #24)
> geert - can you explain the use case for binary input? you do remember it is
> limited to 16KB? it is not intended for binary upload in general?
> 
> michael - we don't have an id per payload (other than the file id maybe)?

not a problem, i can create UUID from the file name 
(it's unique - thanks to file system)
Comment 26 Michael Pasternak 2012-10-18 03:03:38 EDT
(In reply to comment #23)
> If we keep the logic, then the "payloads" collection will contain <payload>
> resources that itself are XML and contain a <file> child element with a
> <content> grandchild element.
> 
> Or do you want a "content" sub-resource below the payload resource, i.e
> "/api/vms/xxx/payloads/yyy/contents"?

i planned [1], but your proposal even better, this way we can restrict
viewing content nicely, i guess the question now "if user should see payloads?"
or it available for admins only and we can stay with [1]. 

[1] /api/vms/xxx/payloads/yyy

  <payload type="floppy" id=yyy>
    <file name="payload.txt">
      <content>
        ...
      </content>
    </file>
  </payload>
Comment 27 Geert Jansen 2012-10-22 15:39:26 EDT
If you do your proposal [1] then you still need to encode the <contents> section, right? I am for your proposal by the way, i do not want to introduce a separate "contents" resource.
Comment 28 Geert Jansen 2012-10-22 15:40:18 EDT
Regarding comment 24: yes i realize this is limited to small files. But we still need binary input.

Note You need to log in before you can comment on or make changes to this bug.