Remember the murder of a 400 error (escape of special symbol in URL/400 Bad request error)

The DJANGO+NGINX+UWSGI deployed site visited a URL with a bad request error, and did not experience this problem when using a Django-brought version of the Web server. The initial judgment is Nginx or UWSGI configuration problem.

Online is because the request header is too large and nginx configuration client_header_buffer_size and large_client_header_buffers too small caused, but in the current state of feeling is not likely. Because the request header is not particularly large. As for what other reasons have not yet been found, so try it first.

Add the following two lines of parameters to the HTTP section of the Nginx configuration file nginx.conf:
Client_header_buffer_size 16k;
Large_client_header_buffers 4 64k;
Nginx defaults to use client_header_buffer_size this buffer to read the header value, if the header is too large, it will use Large_client_header_buffers to read the header value. If the value is set too small and the request header/cookie is too large, it will report a bad request error.

Adjustment parameters reload the configuration file after the restart Uwsgi found that the problem was not resolved.
After careful review only to find that the URL in the request is the parameter contains a special character%, causing the Web server failed to parse the URL correctly, the error was reported.

The following characters have special meanings in the URL:
How symbolic meanings are escaped
+ the + sign in the URL indicates a space%2b
Spaces in a space URL can be encoded with the + number or%20
/delimited directories and subdirectories%2f
? Separating the actual URLs and parameters%3f
% Specifies special characters%25
# indicates bookmark%23
& the delimiter between the parameters specified in the URL%26
= The value of the specified parameter in the URL%3d

The sever, for example, constructs a URL that contains a parameter from the value in the input box of the submitted form.
If the submitted content is "Pkgcr+awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%2bawldb", that is, the value of Q in the parameter is actually "PKGCR+AWLDB"
If the submitted content is "PKGCR awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr+awldb", that is, the value of Q in the parameter is actually "PKGCR awldb"
If the submitted content is "Pkgcr/awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%2fawldb", that is, the value of Q in the parameter is actually "PKGCR/AWLDB"
If the submitted content is "Pkgcr?awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%3fawldb", that is, the value of Q in the parameter is actually "PKGCR?AWLDB"
If the submitted content is "Pkgcr%awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%25awldb", that is, the value of Q in the parameter is actually "PKGCR%AWLDB"
If the submitted content is "Pkgcr#awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%23awldb", that is, the value of Q in the parameter is actually "PKGCR#AWLDB"
If the submitted content is "Pkgcr&awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%26awldb", that is, the value of Q in the parameter is actually "PKGCR&AWLDB"
If the submitted content is "Pkgcr=awldb", the URL of the address bar is displayed as "Xxx/?q=pkgcr%3dawldb", that is, the value of Q in the parameter is actually "PKGCR=AWLDB"

Would you like to construct the URL directly on the server side? For example, the server side of the file has a variable IP, the value is "172.142.%", to construct a URL on the server side for client access, such as "href=?" ip={ip}&q= ' MySQL ' (This assumes {IP} is a way to refer to a variable), then what is the result of clicking on the link?

We will see that because the variable IP contains the special character "%", and "%" has a special meaning in the URL, we construct the URL in the above way is equivalent to "Href=?ip=172.142.%&q=mysql", the Web server resolves the URL can not interpret the% & resulting in an error. For the same reason, some unexpected problems can occur with other special characters, such as having another variable addr, the value "China&america", and the URL being "href=". addr={addr}&q= ' MySQL ', at this point the URL is the equivalent of "Href=?addr=china&america&q=mysql", the Web server will put the URL in the first "&" after the " America "resolves to a different parameter instead of" China&america "as the value of the" addr "parameter as a whole.

So how do you include special characters such as%, &, +, =, and so on in the URL when you need it? The answer is to use the corresponding encoding instead of the special character itself to construct the URL. For example, in the example above, you can replace the IP value with "172.142.%25" and replace the value of addr with "China%26america" so that the URLs are constructed with "href=?ip=172.142.%25&q=mysql" and "href" respectively. = addr=china%26america&q= ' MySQL ', which ultimately resolves the value of the parameter IP in the URL to "172.142.%" and successfully resolves the value of addr to China&america, And it does not cause any other parameter parsing to be confusing.

Finally, the discovery is the 400 error that is caused by the non-transcoding of the Chinese in the access URL.

Ps:js Chinese transcoding (encodeuricomponent)

Remember the murder of a 400 error (escape of special symbol in URL/400 Bad request error)