Kong Caching?

[sbru...@gmail.com]

Trying to set up a Kong Proof of Concept for work to be used as our api gateway layer. One weird thing is happening that I can't figure out and I'm not sure if there is a cache layer built into Kong or not. General setup is :

Kong running on a Debian Google Cloud Engine instance in Docker (both kong-database and kong). Upstream is an ha-proxy instance fronting a kubernetes cluster with an ingress controller handling "internal to the network" requests. Plan would be to run Kong inside of Kubernetes later.

API Configuration looks like :

{

• data:

  [

  • {

    • upstream_url: "http://hello-world.internal.co/",
    • created_at: 1474672178000,
    • request_path: "/hello",
    • id: "35451604-87a8-4abb-b7b8-ca1c82898f01",
    • name: "helloworld",
    • preserve_host: false,
    • strip_request_path: true,
    • request_host: "kong-poc.domain.io"

    }

  ],
• total: 1

}

the internal hello-world world will return with a simple "hello" at the base URL "/" and if a request is made to "/echo/foo" will return foo (or whatever is after /echo).

Here is the weird part. From within the Kong container curl requests to the hello-world.internal works fine. A request to / returns hello and a request to /echo/foo returns foo.

From the Debian host running the container a curl to http://localhost:8000/hello returns hello and http://localhost:8000/hello/echo/foo returns foo.

The part that fails is ..

From an external host making a request from a browser to http://kong-poc.domain.io/hello returns hello and http://kong-poc.domain.io/hello/echo/foo returns hello.

Both requests to the domain on different paths returns the same thing.

If I curl from an external host to the IP address that kong-poc.domain.io resolves to it works as expected with /hello returning hello and /echo/foo returning foo. Same thing from a browser. Using the IP address everything works as expected.

Is there anything magical about using the hostname that within openresty it's caching a response or doing something odd to not properly pass the full path through to the upstream? 

Thanks.

-steve

[sbru...@gmail.com]

Quick follow-up after some more testing. Removing the request_host definition from the API config solved the issue. Seems odd, but it'll let me continue on with the POC.

Thanks.

-steve

[Marco]

Steve,

Kong doesn't do any HTTP caching on the response - this is very odd indeed. 

Since you say that if you make a request from within the container, going through Kong, everything works fine but then when making the request from an external host things start to fail, my question is: is there anything between the external host and Kong that is stripping out the path? So that when Kong receives the request, the requested endpoint is already "/"? 

You can also double-check this by looking at the access logs of Kong, usually at "/usr/local/kong/logs/access.log".

Thanks,

Marco

 Marco Palladino | CTO @ Mashape | mashape.com | +1 (415) 361-3858

--
You received this message because you are subscribed to the Google Groups "Kong" group.
To unsubscribe from this group and stop receiving emails from it, send an email to konglayer+unsubscribe@googlegroups.com.
To post to this group, send email to kong...@googlegroups.com.
Visit this group at https://groups.google.com/group/konglayer.
To view this discussion on the web visit https://groups.google.com/d/msgid/konglayer/813e930d-6f60-49aa-9e03-1ddc2b54ef35%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.