<div dir="ltr"><div>It results in a "415 Unsupported Media Type" at the endpoint, since it wasn't designed to consume application/x-www-form-urlencoded. <br><br>I have experience with some ESB's, and, in most cases, when you have a proxy that is "too smart" it may break your endpoint behavior. And when we are talking about REST APIs, where we are using HTTP as both a transport and application protocol, any apiman interference may break behavior. It's OK for new APIs, but it's very bad for legacy.<br><br>IMHO, if the gateway is deliberately including headers, there won't be any guarantees that the endpoint will be prepared for this. There is a general discussion in Microservices community regarding Smart Pipe X Dumb Pipe that is very relevant to what we are discussing here.<br><br></div><div>Also, I thinkg okhttp is the best alternative when you're developing a client, but is it good to proxy requests? Have you considered Apache HTTP Client + PoolingHttpClientConnectionManager. It has some nice features like "per route" connection pooling that will probably be killing for a Gateway.<br></div><div><br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 9:53 AM Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com">eric.wittmann@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Question: what is the consequence of this problem?<br>
<br>
It turns out that fixing this issue may require fairly extensive changes<br>
to how apiman proxies the request to the back end API. The<br>
http client[1] we are using for this is adding the content length and<br>
content type automatically for DELETE (as well as PUT and POST) if they<br>
are missing. It's doing this because it claims the HTTP spec is<br>
ambiguous on whether DELETE can have a body.<br>
<br>
So how high a priority is this? Is it causing a specific problem for<br>
you, or is it simply something you noticed?<br>
<br>
-Eric<br>
<br>
[1] <a href="http://square.github.io/okhttp/" rel="noreferrer" target="_blank">http://square.github.io/okhttp/</a><br>
<br>
<br>
On 7/25/2016 10:06 AM, Jairo Junior wrote:<br>
> Thanks again.<br>
><br>
> On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a><br>
> <mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>> wrote:<br>
><br>
> JIRA issue created. In case you want to track it:<br>
><br>
> <a href="https://issues.jboss.org/browse/APIMAN-1210" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/APIMAN-1210</a><br>
><br>
> -Eric<br>
><br>
> On 7/25/2016 9:14 AM, Jairo Junior wrote:<br>
> > A client-side javascript app is performing the following request:<br>
> ><br>
> > /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1<br>
> > Host: <a href="http://172.17.0.1:8080" rel="noreferrer" target="_blank">172.17.0.1:8080</a> <<a href="http://172.17.0.1:8080" rel="noreferrer" target="_blank">http://172.17.0.1:8080</a>><br>
> <<a href="http://172.17.0.1:8080" rel="noreferrer" target="_blank">http://172.17.0.1:8080</a>><br>
> > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)<br>
> > Gecko/20100101 Firefox/47.0<br>
> > Accept: application/json, text/plain, */*<br>
> > Accept-Language: en-US,en;q=0.5<br>
> > Accept-Encoding: gzip, deflate<br>
> > Authorization: Bearer $ACCESS_TOKEN<br>
> > Referer: <a href="http://172.17.0.1:3000/" rel="noreferrer" target="_blank">http://172.17.0.1:3000/</a><br>
> > Origin: <a href="http://172.17.0.1:3000" rel="noreferrer" target="_blank">http://172.17.0.1:3000</a><br>
> > Connection: keep-alive<br>
> ><br>
> > /<br>
> > But the gateway is performing the following request to the endpoint:<br>
> ><br>
> > /DELETE /service/rest/resource/7 HTTP/1.1<br>
> > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)<br>
> > Origin: <a href="http://172.17.0.1:3000" rel="noreferrer" target="_blank">http://172.17.0.1:3000</a><br>
> > Accept-Language: en-US,en;q=0.5<br>
> > Accept-Encoding: gzip, deflate<br>
> > Connection: keep-alive<br>
> > Authorization: Bearer $ACCESS_TOKEN<br>
> > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,<br>
> > application/vnd.ms-excel, application/msword,<br>
> > application/vnd.ms-powerpoint, */*<br>
> > Referer: <a href="http://172.17.0.1:3000/" rel="noreferrer" target="_blank">http://172.17.0.1:3000/</a><br>
> > Host: <a href="http://172.17.0.1:8280" rel="noreferrer" target="_blank">172.17.0.1:8280</a> <<a href="http://172.17.0.1:8280" rel="noreferrer" target="_blank">http://172.17.0.1:8280</a>><br>
> <<a href="http://172.17.0.1:8280" rel="noreferrer" target="_blank">http://172.17.0.1:8280</a>><br>
> > Content-Type: application/x-www-form-//urlencoded<br>
> > Content-Length: 0<br>
> ><br>
> > /<br>
> > Resulting in a 415 Unsupported Media Type at the endpoint.<br>
> ><br>
> > GET, POST and PUT requests are OK.<br>
> ><br>
> > Only using CORS Policy for this endpoint:<br>
> ><br>
> > /Access-Control-Allow-Origin: *<br>
> > Access-Control-Allow-Credentials: true<br>
> > Access-Control-Allow-Headers: accept, authrotization, content-type<br>
> > Access-Control-Allow-Methods: GET, POST, PUT, DELETE<br>
> > Access-Control-Max-Age: 3600/<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Apiman-user mailing list<br>
> > <a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/apiman-user</a><br>
> ><br>
><br>
</blockquote></div>