[wildfly-dev] Steamable content in management API responses

[Brian Stansberry]

Ok, good to know. I'll just support a custom HTTP header. The query 
param in the URL works too, so people can choose the approach they want.

On 10/4/14, 9:11 PM, Jason T. Greene wrote:
> DMR as a form encoded value? I really don't think we should allow this. Form encoding is for web browsers typing in values and it will set off the extra security checks we have for cross origin posting (this is the kind of thing a JS hack would do to get your browser to send up arbitrary management ops to the server)
>
> We probably should use an HTTP header if we don't want it in the payload, perhaps in combination with an Accept.
>
>
>> On Oct 3, 2014, at 5:41 PM, Brian Stansberry <brian.stansberry at redhat.com> 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 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
>> _______________________________________________
>> 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