Likewise for Kibana. #4959

For the Kibana case, I observe a sequence of correctly proxied GETs e.g. to:

fontawesome-webfont...
/api/v1beta1/proxy/services/kibana-logging/font

but then I see:

app.js
/api/v1beta1/proxy/services/app

which fails because I assume what was really needed is:

app.js
/api/v1beta1/proxy/services/kibana-logging/app

and a curl against that gives a pile of plausible Javascript.

After a little thought, I think what's going on here is that web clients can't tell that kibana-logging is a directory without the trailing slash. One thing we could potentially do to help is to redirect (301) from kibana-logging to kibana-logging/, since I don't think the former is useful for anyone.

cc @nikhiljindal

How are we generating that URL? Can we append a "/" at the end while generating the URL?
Doing a redirect or auto-adding "/" in the proxy for all requests could break other requests.

The URL is not generated anywhere. It is assumed that
'/proxy/service/' would work.

On Tue, Mar 24, 2015 at 7:04 PM, Nikhil Jindal notifications@github.com
wrote:

How are we generating that URL? Can we append a "/" at the end while
generating the URL?
Doing a redirect or auto-adding "/" in the proxy for all requests could
break other requests.

—
Reply to this email directly or view it on GitHub
#4958 (comment)
.

I discussed this with @vishh and @lavalamp.
To clarify, proxy server does not require a trailing slash. It works as expected (gives the same response with or without a trailing slash)
The client code, on the other hand, expects it to be rendered on a path with a trailing slash and breaks when that is not the case.
Ideally, we should fix the client code.
For now, we decided to update proxy to send a 301 redirect from a path without a trailing slash to a path with a trailing slash.
I will send a PR for this.

By "client code" do you mean things like Elasticsearch and Kibana?

Yes. The code being rendered on those paths.

I agree with what @nikhiljindal said, I just want to clarify that it's not necessarily a "broken" client, just one with different expectations. Adding the 301 redirect seems like an easy way to satisfy such clients and reduce user pain.

Not fixed because of #6114

On GCE, the redirection is still not happening because the request is upgraded before we get a chance to redirect #6264

On localhost, the redirection works fine but we are unable to load the css and js files because of #5339 (comment)

@nikhiljindal Is proxy still supported in v1beta3? I vaguely remember that we wanted to remove it.

I tried this: https://ip/api/v1beta3/proxy/namespace/default/services/monitoring-grafana/ but got NotFound error.

Access to cluster-level logging components depends on the proxy so avoid making ELBs.
Elasticsearch and Kibana are accessed via the v1beta3 service proxy.

Although the trailing slashes are no longer required.

Kubernetes master is running at https://104.197.12.87
elasticsearch-logging is running at https://104.197.12.87/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging
kibana-logging is running at https://104.197.12.87/api/v1beta3/proxy/namespaces/default/services/kibana-logging
kube-dns is running at https://104.197.12.87/api/v1beta3/proxy/namespaces/default/services/kube-dns