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

> 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