Re: [wildfly-dev] Steamable content in management API responses

On Oct 3, 2014, at 5:41 PM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: 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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev