Can't reach endpoint when proxy configured

bjwschaap commented 7 years ago

When I define a proxy on an endpoint, the request fails because the proxy gets an invalid request url. Steps to reproduce:

Create SWAPI endpoint as per quick-start tutorial: https://docs.gravitee.io/apim_quickstart_publish.html
Go to 'endpoints' in the 'gateway' tab, edit endpoint
Add a HTTP Connection proxy, only host and port, no username/password

Test the endpoint with curl, request fails with an error from (in our case) Squid proxy:


<div id="content">
<p>The following error was encountered while trying to retrieve the URL: <a href="http://swapi.cohttp://swapi.co/api/">http://swapi.cohttp://swapi.co/api/</a></p>

Invalid URL


I would expect the request to simply succeed. Somehow the request url gets malformed due to the proxy configuration.

I'm using gravitee 1.1.0 through the provided Docker images, using the example compose file.

Logging:

local_gateway_1 | 14:05:40.008 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.r.h.i.DefaultReactorHandlerRegistry - Register a new handler for Api{id='8283b503-a1fe-4014-83b5-03a1fe3014aa', name='SWAPI', version='1.0'} on path /myfirstapi local_gateway_1 | 14:05:40.016 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.h.c.l.s.LoadBalancerFactory - Create a load-balancer instance of type io.gravitee.gateway.http.core.loadbalancer.SingleEndpointLoadBalancerStrategy@99681c8 local_gateway_1 | 14:05:40.022 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.handlers.api.ApiReactorHandler - API handler is now starting, preparing API context... local_gateway_1 | 14:05:40.024 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.http.vertx.VertxHttpClient - Create HTTP Client with configuration: local_gateway_1 | 14:05:40.024 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.http.vertx.VertxHttpClient - HTTP {ConnectTimeout='5000', KeepAlive='true', IdleTimeout='60', MaxChunkSize='8192', MaxPoolSize='100', MaxWaitQueueSize='-1', Pipelining='false', PipeliningLimit='10', TryUseCompression='true'} local_gateway_1 | 14:05:40.024 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.http.vertx.VertxHttpClient - Proxy {Type='HTTP, Host='www-proxy.*****.nl', Port='8082', Username='null'} local_gateway_1 | 14:05:40.024 [sync-1] [8283b503-a1fe-4014-83b5-03a1fe3014aa] INFO i.g.g.handlers.api.ApiReactorHandler - API handler started in 2 ms and now ready to accept requests on /myfirstapi/*


_(I redacted the proxy address)_

Doing the actual API request does not show any logging.

brasseld commented 7 years ago

Hi @bjwschaap,

As far as I understand, the request is not properly handled by the Squid proxy.

We have exactly the same Swapi API in our demo environnement and it's still available by calling this url: https://demo.gravitee.io/gateway/swapi?api-key=40886604-5450-408d-b3ff-249545ee8fdf

According to me, there are two reasons for your problem:

Invoking the Swapi API results on a 301 status code (permanent redirection)
We have an issue with 1.1.0 that can be relative to this one: #377

One solution could be to use a nightly build to give a try. The other one is to use an other backend API. In that case, you can use our APIs from: https://api.gravitee.io/.

FYI, we are currently on a quickstart rewriting process to use these APIs to replace Swapi (which is not our own API).

Finally, one quick way to see what's going wrong while doing call is to use the Dump HTTP requests feature:

Waiting for your feedback.

Regards,

bjwschaap commented 7 years ago

Hi David,

You are correct the proxy does not handle the request, but it can't since the request it gets from the gateway is malformed.

I added another API, just as an example http://httpbin.org. I've set the dump HTTP headers option as you requested. Now when I test:

curl -H 'X-Gravitee-Api-Key: ba84f1c2-6f76-400f-ad48-blahblahblah' http://localhost:8000/httpbin/ip

...
The following error was encountered while trying to retrieve the URL: <a href="http://httpbin.orghttp://httpbin.org/ip">http://httpbin.orghttp://httpbin.org/ip
...

Watching the logs with docker-compose logs --follow does not show any logging when I do the request.

Doing the exact same thing on my laptop, with the exact same Docker version, same docker-compose files, and Docker image versions, which doesn't need a proxy succeeds without any problems.

Although the description is somewhat cryptic for someone that is new to Gravitee, it does seem like I might be hitting #377 indeed.

bjwschaap commented 7 years ago

brasseld commented 7 years ago

Hi @bjwschaap,

So I really think that #377 may resolve your issue. What I can do is to provide you with a patched jar you have to replace in the gateway lib/ directory.

About the logs and Docker logs, it think it's due to the fact that there is a dedicated log for HTTP dumps. Let's have a look to a file named gravitee-httpdump.log.

Although the description is somewhat cryptic for someone that is new to Gravitee, it does seem like I might be hitting #377 indeed.

You are absolutely right, sorry for that enigmatic issue description...

bjwschaap commented 7 years ago

Hi @brasseld

No problem. I found the log:

15:15:21.173 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> Rewriting: /httpbin/ip/ -> http://httpbin.org/ip/
15:15:21.173 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> GET http://httpbin.org/ip/
15:15:21.176 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> Host: xxxxxxxxx.nl:8000
15:15:21.176 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> User-Agent: curl/7.49.1
15:15:21.176 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> Accept: */*
15:15:21.176 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> Via: 1.1 172.17.0.3:8000, 1.1 172.17.0.2:8000, 1.1 hostXXX.xxxxxxxxx.nl:8000
15:15:21.176 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> Connection: Keep-Alive
15:15:21.177 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> X-Gravitee-Transaction-Id: c37a02bc-9066-401f-ba02-bc9066301fbc
15:15:21.177 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc >> upstream proxying complete
15:15:21.194 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << HTTP Status - 400
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Server: squid/3.1.23
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Mime-Version: 1.0
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Date: Wed, 21 Dec 2016 15:15:21 GMT
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Content-Type: text/html
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Content-Length: 3217
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << X-Squid-Error: ERR_INVALID_URL 0
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Vary: Accept-Language
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Content-Language: en
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << X-Cache: MISS from KA-Proxy
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << X-Cache-Lookup: NONE from Proxy:8082
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Via: 1.0 Proxy (squid/3.1.23)
15:15:21.195 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304 << Connection: close
15:15:21.196 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc << proxying content to downstream: 669 bytes
15:15:21.196 >> 3c48927d-2cc4-4ea3-8892-7d2cc42ea304/c37a02bc-9066-401f-ba02-bc9066301fbc << <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>ERROR: The requested URL could not be retrieved</title>
...
The following error was encountered while trying to retrieve the URL: <a href="http://httpbin.orghttp://httpbin.org/ip">http://httpbin.orghttp://httpbin.org/ip
...

Strange thing is, that is does show the correct GET http://httpbin.org/ip/, but this somehow is not what is actually sent to the proxy. Unfortunately I don't have access to the Squid proxy to confirm this from the proxy logging as well..

A patched Jar would be great so I can test.

brasseld commented 7 years ago

Thanks for the log @bjwschaap.

I'm now convinced about the link with #377.

Please get the jar from https://dl.dropboxusercontent.com/u/108753749/gravitee-gateway-http-client-vertx-1.2.0-SNAPSHOT.jar and replace the one from graviteeio-gateway/lib/ (do not forget to remove the same jar in 1.1.0 version).

Thanks for your feedback.

bjwschaap commented 7 years ago

Thank you @brasseld!

I 'replaced' the jar by 'shadowing' it mounting the new jar over the existing one by specifying it as a Docker volume, and restarting the container. With the new jar it works like a charm!

Thank you for your excellent assistance and quick response! When will 1.2.0 be released?

brasseld commented 7 years ago

Thanks to you for your appreciate feedback ! Release 1.2.0 is scheduled for 10.01.2017.

I'm closing this issue as it is a duplicate of #377

gravitee-io / issues

Can't reach endpoint when proxy configured #390