Just assisted a customer in an interesting issue which I thought might be helpful for others as well. The problem my customer faces was that he's using a cliebt REST application which tried to update data on the REST server running on tWAS using the HTTP PATCH method. When the PATH request was sent the client application an HTTP return code 400 was returned to the client. Sending the patch request directly to the WebContainer transport worked nicely.
First we managed to recreate the problem using curl. So the request was like this one:
curl -k --noproxy "*" -X PATCH --http1.1 --data '{"Operations":[{"op":"add","path":"members","value":[{"value":"BXXYY"}]}],"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"]}' -i -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: Basic YXasdfadsfasdfadsfdsaf" -H "User-Agent: PostmanRuntime/7.16.3" -H "Cache-Control: no-cache" -H "Postman-Token: xxxxyyyyzzz" -H "Accept-Encoding: gzip, deflate" -H "Connection: keep-alive" https://my.host.name/myapp/groupman/Groups/restobject
Checking the plugin logfile let us to the plugin property `AcceptAllContent` which is set to false by default.
Reading the documentation at https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/rwsv_plugincfg.html#rwsv_plugincfg__AcceptAllContent clarified the issue. If AcceptAllContent=false is set data payload is namely accepted only for POST and PUT requests.
Hence the solution for us was to set AcceptAllContent=true and to restart the HTTP server so that the plugin is reloaded! That made things working!
Just make sure that you configure this property for the plugin in the WAS Admin Console as well as otherwise it might be overwritten after the next re-generation of the plug-cfg.xml :)
------------------------------
Hermann Huebler
2innovate IT Consulting GmbH
Vienna
Austria
#IBMChampion
------------------------------