nginx variable "merge_slashes" does not work for Kong

[alokrbl]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

Kong 2.8.3 and Kong 3.1.1

Current Behavior

We have an API which is an OCSP responder that accepts both POST and GET methods.
We have an issue with the GET method when the OCSP request URL contains multiple successive slashes.

URL is in this format :
'GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}'

By default, Kong is merging those multiple slashes.

We referred below mentioned links and added 2 environment variables to disable it ( as value "off") and deployed kong ( tried adding either one at a time and both too)

• KONG_NGINX_HTTP_MERGE_SLASHES ( for http context)
• KONG_NGINX_PROXY_MERGE_SLASHES ( for server context)

above env variables are added correctly in /opt/app/var/nginx-kong.conf but looks like kong is not respecting this and sending this with merging the slash.

Doc links Referred:
https://docs.konghq.com/gateway/latest/reference/configuration/#nginx-injected-directives-section
https://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes

Expected Behavior

Slashes used in uri should not be merged.

Steps To Reproduce

use the url with slashes with base64 encoding.

• received url value:
  "/ejbca/publicweb/status/ocspMHoweDBRME8wTTAJBgUrDgMCGgUABBQNw3RqyC6xHUNZEnsPwJ74U6x+LgQUoxGE7mYCotQBEo+9BE3//vQ7pDYCFAC5lBCKmOU5fesTX5vnnmwfE5N6oiMwITAfBgkrBgEFBQcwAQIEEgQQz6Ap6eUOHOS8ethetqUC7Q=="

• sent url value:
  "/ejbca/publicweb/status/ocsp/MHoweDBRME8wTTAJBgUrDgMCGgUABBQNw3RqyC6xHUNZEnsPwJ74U6x+LgQUoxGE7mYCotQBEo+9BE3/vQ7pDYCFAC5lBCKmOU5fesTX5vnnmwfE5N6oiMwITAfBgkrBgEFBQcwAQIEEgQQz6Ap6eUOHOS8ethetqUC7Q=="

Anything else?

No response

[Oyami-Srk]

Kong matches the URL and proxies it with the normalized URL which always merges slashes.
This is expected for not respecting this nginx directive. Currently, there is no option to bypass it.

[bungle]

Is it possible to url encode the token before it is put into path?

[Oyami-Srk]

I'd like to suggest passing base64 as a part of the URL should be done with URL encoding.

According to RFC2396, slash is a reserved character and must be escaped.

Although HTTP RFC requires that a transparent proxy must not rewrite the path of the request URI, Kong is not a transparent proxy.

Personally, I don't think passing Base64 by URL is a good idea. For example, Base64 is case-sensitive, and HTTP RFC doesn't require any case sensitivity of URLs. Although most software doesn't normalize URLs to lower-case or upper-case, it can be a problem if you want to apply some middleware that unfortunately does that.

I'll close this issue for now. Feel free to reopen it if you have any other concerns.

[younid]

Hello @Oyami-Srk ,

Could you please explain what is for you "must be escaped" ?
Sorry to ask that but did some tests and I can't have it working even when I have the double slashes "//" replaced by their url encoded value "%2F%2F". Result is that Kong replace the url encoded values by a simple slash when forwarding request URL to the upstream server.

Maybe I missed a step or did not correctly understood your answer.
Please help to have this topic fixed even when using Kong for OCSP responder.
For more details about why we try to make it work with GET method you can have a look on the RFC 6960

Regards

[Oyami-Srk]

Ok, I thought escaping to %2F%2F should work and sending %2F%2F to upstream, but seems like it didn't.
One mitigation is passing base64 by body or parameter after ?.
Feel free to reopen this issue if you want. Thanks.

[younid]

Hello @Oyami-Srk ,

I tried to reopen this issue but I did managed to find any option for that.
Could you please tell me how I should do ?

Regards,
Youness

[Oyami-Srk]

I'll reopen this for you.
Overall, Kong is not a transparent proxy and will always normalize the URI according to the documentation. But the doc didn't clarify that how percent-encoded triplets of reserved characters are being treated.
It could be designed behavior but undocumented. I'm not very sure about that. Could you please take a look into that? @bungle