Bug related to basePath on x-google-allow in ESP

[AL]

I am using ESP to verify API keys for services implemented in a container. Before adding ESP, the service runs in its own container with health check available at url /healthz. The deployment is exposed in a service of type NodePort, which is in turn exposed via an ingress.

After adding the ESP to the pod, I noticed that the health check is failing with the following from the logs:

14:57:49.666us-central1-a404Endpoints management skipped for an unrecognized HTTP call: GET /healthz

Expand all | Collapse all

 

 

 

 

 

 

 

 

 

 

 

 

}

 

 

When this is happening I had the following in swagger.yaml.

# basePath prefixes all resource paths

basePath: /v1

# Default to route all calls such as /docs and /healthz

x-google-allow: all

I tried adding "/healthz" to swagger.yaml and that solved the problem, which means that setting "x-google-allow" to "all" isn't doing what it was supposed to do. After changing the basePath to "/", I am getting the normal health check responses from the log file.

15:13:14.971us-central1-a2001 msMethod: 0.ees_api_endpoints_cds_dev_155819_cloud_goog.Google_Autogenerated_Unrecognized_Get_Method_Call

Expand all | Collapse all

 

 

 

 

 

 

 

 

 

 

 

 

 

 

}

 

 

Now my swagger.yaml looks like the following:

# basePath prefixes all resource paths

basePath: /

# Default to route all calls such as /docs and /healthz

x-google-allow: all

Apparently having "/v1" in the basePath changes how ESP's interpretation of "x-google-allow".

It's really annoying not being able to define a basePath in swagger. Could you please investigate and see if there is indeed an implementation issue between "basePath" and "x-google-allow"?

Thanks.

AL

[qiwz...@google.com]

There is a bug in how ESP handles "basePath" for "x-google-allow" = all.  If your basePath is /v1,   allow-all only allow /v1/** to go through.  It should have allowed /** to go through.

Well,  we are redesigning the "x-google-allow" feature. It will be deprecated.   The new feature is called supporting "unspecified-paths", which is more flexible. 

At the mean time, you may have to change your basePath to / to work around this bug before the new feature is release.   we hope to get it out in Q4.

[abhi...@busuncle.sg]

Any updates to this?

I have a large API and have to manually add "/api/" to every single resource currently, because basePath and x-google-allow don't work together. It's quite painful.

[Qiwen Zhang]

According to this doc.  This behaviors is by design, some users are counting on such behaviors. 

[abhi...@busuncle.sg]

The doc states that as long as basePath is configured with a prefix, that is "x.com/api/", "x-google-allow: all" should any unconfigured method such as "x.com/api/unconfigured_users" to go through.

In reality, it doesn't allow it.

[Qiwen Zhang]

In that case, it is a bug, we need to debug it.   Please open an issue here with followings

1) your service config

2) the request you tried that did not go through.  

If you can get ESP debug log, it will be great.  you can turn it on by adding a ESP flag --enable_debug,  the log will be inside the ESP container, in its /var/log/nginx/error.log

Thanks

-Wayne