[Apiman-user] Content-type header included in gateway DELETE requests to endpoint
Jairo Junior
junior.jairo1 at gmail.com
Tue Jul 26 17:53:07 EDT 2016
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.
=)
On Tue, Jul 26, 2016 at 10:49 AM Eric Wittmann <eric.wittmann at redhat.com>
wrote:
> 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 at redhat.com
> > <mailto:eric.wittmann at 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 at redhat.com <mailto:eric.wittmann at redhat.com>
> > > <mailto:eric.wittmann at redhat.com
> > <mailto:eric.wittmann at 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 at lists.jboss.org
> > <mailto:Apiman-user at lists.jboss.org>
> > <mailto:Apiman-user at lists.jboss.org
> > <mailto:Apiman-user at lists.jboss.org>>
> > > > https://lists.jboss.org/mailman/listinfo/apiman-user
> > > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160726/eba193d3/attachment.html
More information about the Apiman-user
mailing list