[Apiman-user] Content-type header included in gateway DELETE requests to endpoint

Tue Jul 26 09:49:35 EDT 2016

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
>     >     >
>     >
>