-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect(?) decoding of forwarded URL #688
Comments
This is the same as #675 if I'm correct |
@thibaultcha not really. As part of our performance tests we're just replaying our access logs in a way that they go through Kong. We then replay the same access log but this time we just contact the upstream API and hence we bypass Kong. On top of this we've Grafana which lets us compare response times and HTTP codes and it came to my attention that we have some 404 when we go through Kong. After further investigation I noticed that we have some requests in our log files which are already encoded, ex: /v1/track/CR/101.226.89.123247c5a5055f4f1753a6ec25da8a49202/1662321.4049.CN.14465.1662321_3034_SPANK_UPL_CN_3034_10310_ADV27882_12897C_%2F_mobile?apikey=API_KEY pay close attention to 2F ;). When this request goes through Kong it gets decoded before being sent to the upstream API server, which receives: /v1/track/CR/101.226.89.123247c5a5055f4f1753a6ec25da8a49202/1662321.4049.CN.14465.1662321_3034_SPANK_UPL_CN_3034_10310_ADV27882_12897C_/_mobile?apikey=API_KEY Do you see the difference? The %2F was decoded before being sent... |
Sorry was on mobile. It would seem at first glance that this is due to nginx's proxying. As pointed out in the docs, which were also referred to here and here, the URI part of the In our case, we have:
in the configuration, and in -- Setting the backend URL for the proxy_pass directive
ngx.var.backend_url = get_backend_url(api)..uri It would then seem like the computed
and as pointed out by those sources, the
I will try to tackle this when I'll have some time (which might not be anytime soon due to the Cassandra driver). Thank you for spotting this btw! Nice find. |
@thibaultcha I will take care of setting up a test scenario for reproducing this. This is kinda blocking for us, given that some of this calls are related to tracking sales/stats ... and we all know how important is to keep customers happy :). I will keep you posted. |
@thibaultcha I have put together a test scenario which illustrates de issue we're facing, see here: https://github.com/yoanisgil/kong-encode-request The demo itself it's quite simple:
When I call the echo server through Kong I see how %2F% gets decoded and then forwarded. When a direct call is made, or through nginx, the character %2F does not get decoded. Bests, Yoanis. |
I have this API which is defined as follows:
when I use Kong to query the upstream API:
curl http://vm1.ygil.dev.lan:9005/v1/track/CR/101.226.89.123247c5a5055f4f1753a6ec25da8a49202/1662321.4049.CN.14465.1662321_3034_SPANK_UPL_CN_3034_10310_ADV27882_12897C_%2F_mobile?apikey=API_KEY
I get this:
which is the response from the upstream server complaining that the provided resource does not exists.
Now, when I bypass Kong and contact directly the upstream API:
http://aws038:8000/craktracking-track/v1/track/CR/107.77.70.6388897fcf61c6a404d41ef51a50379bbe/1.1233.US.4657.TFA_151785_XVID_SQU_US_OTHERS_22805C_NDP_NDP17877_MBAK_GEN_POS2_ALL_MBAK_TPS_POS?apikey=API_KEY
I get this:
If you look close to the request path/parameters you will notice that there is a %2F (/):
/v1/track/CR/101.226.89.123247c5a5055f4f1753a6ec25da8a49202/1662321.4049.CN.14465.1662321_3034_SPANK_UPL_CN_3034_10310_ADV27882_12897C_%2F_mobile?apikey=API_KEY
it looks like either Kong or nginx are performing a URL decode before forwarding the request to the upstream server:
/v1/track/CR/101.226.89.123247c5a5055f4f1753a6ec25da8a49202/1662321.4049.CN.14465.1662321_3034_SPANK_UPL_CN_3034_10310_ADV27882_12897C_/_mobile?apikey=API_KEY
Any ideas?
The text was updated successfully, but these errors were encountered: