8:49 a.m.
OK thanks for the info - very helpful.
Regarding OK vs Apache - there is a design reason why OK is being used
vs. Apache that is perhaps not that interesting to get into. It has to
do with the way in which we stream the body of the request (and response).
I agree with the assessment of smart vs. dumb proxies - the apiman
gateway should definitely not be adding anything to the conversation
that wasn't configured via one of the policies. I definitely consider
this a bug, but I think it may require a fairly substantial rewrite of
the http connector to fix it. :( I'm not against doing it, but I was
hoping for a quick fix.
-Eric
On 7/26/2016 9:30 AM, Jairo Junior wrote:
It results in a "415 Unsupported Media Type" at the
endpoint, since it
wasn't designed to consume application/x-www-form-urlencoded.
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.
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.
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.
On Tue, Jul 26, 2016 at 9:53 AM Eric Wittmann <eric.wittmann(a)redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:
Question: what is the consequence of this problem?
It turns out that fixing this issue may require fairly extensive changes
to how apiman proxies the request to the back end API. The
http client[1] we are using for this is adding the content length and
content type automatically for DELETE (as well as PUT and POST) if they
are missing. It's doing this because it claims the HTTP spec is
ambiguous on whether DELETE can have a body.
So how high a priority is this? Is it causing a specific problem for
you, or is it simply something you noticed?
-Eric
[1] http://square.github.io/okhttp/
On 7/25/2016 10:06 AM, Jairo Junior wrote:
> Thanks again.
>
> On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann
<eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>
> <mailto:eric.wittmann@redhat.com
<mailto:eric.wittmann@redhat.com>>> wrote:
>
> JIRA issue created. In case you want to track it:
>
> https://issues.jboss.org/browse/APIMAN-1210
>
> -Eric
>
> On 7/25/2016 9:14 AM, Jairo Junior wrote:
> > A client-side javascript app is performing the following
request:
> >
> > /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
> > Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
<http://172.17.0.1:8080>
> <http://172.17.0.1:8080>
> > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
> > Gecko/20100101 Firefox/47.0
> > Accept: application/json, text/plain, */*
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > Authorization: Bearer $ACCESS_TOKEN
> > Referer: http://172.17.0.1:3000/
> > Origin: http://172.17.0.1:3000
> > Connection: keep-alive
> >
> > /
> > But the gateway is performing the following request to the
endpoint:
> >
> > /DELETE /service/rest/resource/7 HTTP/1.1
> > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; SV1)
> > Origin: http://172.17.0.1:3000
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > Connection: keep-alive
> > Authorization: Bearer $ACCESS_TOKEN
> > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> > application/vnd.ms-excel, application/msword,
> > application/vnd.ms-powerpoint, */*
> > Referer: http://172.17.0.1:3000/
> > Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
<http://172.17.0.1:8280>
> <http://172.17.0.1:8280>
> > Content-Type: application/x-www-form-//urlencoded
> > Content-Length: 0
> >
> > /
> > Resulting in a 415 Unsupported Media Type at the endpoint.
> >
> > GET, POST and PUT requests are OK.
> >
> > Only using CORS Policy for this endpoint:
> >
> > /Access-Control-Allow-Origin: *
> > Access-Control-Allow-Credentials: true
> > Access-Control-Allow-Headers: accept, authrotization,
content-type
> > Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> > Access-Control-Max-Age: 3600/
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>