Encoded url

Server NGINX
1

Hello everyone,
I’ve nginx 1.2.5 and I’ve an issue about encoded URLs.
Is there a way to make nginx accepts URL like the following:

http://www.mywebsite.com/image.php%3Fid%3D12345

as equivalent of the following?

http://www.mywebsite.com/image.php?id=12345

In my current configuration, the first URL is 404 not found, and the
second
one works.

Many thanks

PB

Posted at Nginx Forum:

2

For mywebsite.com is available for purchase - Sedo.com, the uri is
“/image.php?id=12345” after decoded,
so nginx may try to find file with name “image.php?id=12345” based on
your
config file. That’s why you got 404.
For mywebsite.com is available for purchase - Sedo.com, the uri is “/image.php”
and argument is “id=12345”.

If you want a uri with argument, the ‘?’ should not be encoded, check
this
https://tools.ietf.org/html/rfc3986#section-3

URI = scheme “:” hier-part [ “?” query ] [ “#” fragment ]

3

On Sat, May 23, 2015 at 01:56:32PM -0400, pierob83 wrote:

Hi there,

        I've nginx 1.2.5 and I've an issue about encoded URLs.

I’ve not tested this on 1.2.5; but the concept should remain the same.

Is there a way to make nginx accepts URL like the following:

mywebsite.com is available for purchase - Sedo.com

as equivalent of the following?

mywebsite.com is available for purchase - Sedo.com

nginx won’t directly accept the two as equivalent, because they are not,
in important ways.

There are two approaches you can take.

  • redirect the client to the correct url, and let them request that

  • proxy_pass the correct url back into the same nginx instance

I do not know the full correct nginx syntax; but if you are happy that
there will not be other encoded characters in the request that must
remain
encoded for it to be a valid url, you could try matching on the encoded
? in the request, and using the unencoded version in the next step.

That is:

location ~ ? { return 301 $uri; }

or

location ~ ? {
proxy_pass http://[your bit here]$uri;
proxy_set_header Host $host;
}

where [your bit here] is an ip:port that corresponds to this server’s
“listen” directive, and the proxy_set_header bit is to ensure that
this server’s server_name matches (and the right thing is used in any
response headers).

Good luck with it,

f

Francis D. [email protected]