<div dir="ltr">I see. I was introduced to apiman's codebase last week, so, it's just a rookie's opinion here. Glad I could help and thanks for the fast feedbacks. =)</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 10:49 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">OK thanks for the info - very helpful.<br>
<br>
Regarding OK vs Apache - there is a design reason why OK is being used<br>
vs. Apache that is perhaps not that interesting to get into. It has to<br>
do with the way in which we stream the body of the request (and response).<br>
<br>
I agree with the assessment of smart vs. dumb proxies - the apiman<br>
gateway should definitely not be adding anything to the conversation<br>
that wasn't configured via one of the policies. I definitely consider<br>
this a bug, but I think it may require a fairly substantial rewrite of<br>
the http connector to fix it. :( I'm not against doing it, but I was<br>
hoping for a quick fix.<br>
<br>
-Eric<br>
<br>
<br>
On 7/26/2016 9:30 AM, Jairo Junior wrote:<br>
> It results in a "415 Unsupported Media Type" at the endpoint, since it<br>
> 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<br>
> proxy that is "too smart" it may break your endpoint behavior. And when<br>
> we are talking about REST APIs, where we are using HTTP as both a<br>
> transport and application protocol, any apiman interference may break<br>
> 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<br>
> any guarantees that the endpoint will be prepared for this. There is a<br>
> general discussion in Microservices community regarding Smart Pipe X<br>
> Dumb Pipe that is very relevant to what we are discussing here.<br>
><br>
> Also, I thinkg okhttp is the best alternative when you're developing a<br>
> client, but is it good to proxy requests? Have you considered Apache<br>
> HTTP Client + PoolingHttpClientConnectionManager. It has some nice<br>
> features like "per route" connection pooling that will probably be<br>
> killing for a Gateway.<br>
><br>
><br>
><br>
><br>
> On Tue, Jul 26, 2016 at 9:53 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>
> 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<br>
> <<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a> <mailto:<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><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<br>
> 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>
> > <<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<br>
> endpoint:<br>
> > ><br>
> > > /DELETE /service/rest/resource/7 HTTP/1.1<br>
> > > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT<br>
> 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>
> > <<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,<br>
> 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><br>
> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a>><br>
> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a><br>
> <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>
><br>
</blockquote></div>