[wildfly-dev] Steamable content in management API responses

Brian Stansberry brian.stansberry at redhat.com
Fri Oct 3 18:41:12 EDT 2014


FYI, https://issues.jboss.org/browse/WFCORE-148 is the JIRA for this.

I didn't want to encode useStreamAsResponse in the DMR as an operation 
header, as this isn't about how the core management layer executes the 
op, just how the http server deals with sending the response.

But since it's Friday you guys inspired me to go ahead and handle 
application/x-www-form-urlencoded

So I updated my branch and with the 3rd commit, a proper form with the 
DMR as the value associated with a form key 'dmr' now works:

curl --digest -L -D - http://localhost:9990/management --header 
"Content-Type: application/x-www-form-urlencoded" -u 
bstansberry:admin.1234 -d 
'dmr={"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' 
-d useStreamAsResponse

A caller sending dmr-encoded can even hint at that with the "Accept" header:

curl --digest -L -D - http://localhost:9990/management --header 
"Content-Type: application/x-www-form-urlencoded" --header "Accept: 
application/dmr-encoded" -u bstansberry:admin.1234 -d 
'dmr=bwAAAAQACW9wZXJhdGlvbnMADnJlYWQtYXR0cmlidXRlAAdhZGRyZXNzbAAAAAFvAAAAAQAJc3Vic3lzdGVtcwAHbG9nZ2luZwAEbmFtZXMACnNlcnZlci1sb2cAC2pzb24ucHJldHR5SQAAAAE=' 
-d useStreamAsResponse

That hack of using 'Accept' and not just 'Content-Type' to trigger 
dmr-encoded handling was already there, so don't blame me. ;)

On 10/2/14, 7:46 PM, Jason T. Greene wrote:
> It's proper. It's  sending a content type of application/JSON not form data. So if you want the value other than the URL param, it would have to be in the DMR and read from the model node
>
>>> On Oct 2, 2014, at 6:01 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>>
>>> 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
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list