[wildfly-dev] Steamable content in management API responses

[David M. Lloyd]

On 10/02/2014 05:46 PM, Brian Stansberry wrote:
> On 10/1/14, 9:52 AM, Brian Stansberry wrote:
> <snip/>
>
>>
>> TODOs:
>>
>
>>
>> 5) Make sure POST works well. My assumption is this is lower priority,
>> as the real use cases would likely use a GET.
>>
>
> If you include the useStreamAsResponse as a query param in the URL, as
> with GET, it works. If you do the proper POST thing and encode the query
> param in the request body it doesn't. The DomainApiHandler tries to
> parse the entire request body into a ModelNode and a leading
> useStreamAsResponse& or trailing &useStreamAsResponse fails.
>
> I'm fine with just requiring encoding the param in the URL, even though
> it isn't proper. I don't plan on spending energy near term on parsing it
> out of a POST request body.
>
> If you're curious to try this with my resp-stream branch, this works:
>
> curl --digest -L -D -
> http://localhost:9990/management?useStreamAsResponse --header
> "Content-Type: application/json" -u user:password -d
> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}'
>
> This doesn't:
>
> curl --digest -L -D - http://localhost:9990/management --header
> "Content-Type: application/json" -u user:password -d
> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}'
> -d useStreamAsResponse

Maybe because the content type isn't multipart/form-data?  I think if 
you're going to send or receive content alongside the main payload, 
you'll have to use a multipart request and/or response (this also 
implies some accept-ish header stuff too IIRC).
-- 
- DML