Understanding_nginx

As we came across this question often ourselves, I decided to write a quick article about the $request_uri handling of nginx. According to the ngx_http_core_module-documentation, the variable $request_uri is defined as:

full original request URI (with arguments)

While this seems clear at first, it is not well defined. We have done some trial and error and can best explain it by examples using real cases:

1. For the URL:
   https://www.webhosting24.com/understanding-nginx-request_uri/
   the nginx variable $request_uri is populated as follows:
   /understanding-nginx-request_uri/
2. For the URL:
   https://www.webhosting24.com/cp/cart.php?a=add&domain=register
   the nginx variable $request_uri is populated as follows:
   /cp/cart.php?a=add&domain=register
3. For the URL:
   https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2
   the nginx variable $request_uri would still be populated only as follows:
   /Protocols/rfc2616/rfc2616-sec3.html
   as #sec3.2 is just a fragment/comment/anchor and not part of the URI.

Simply put, the $request_uri contains the full path (/understanding-nginx-request_uri/ in example 1 or /cp/cart.php in example 2 above) and any argument strings that may be present (“?a=add&domain=register” in example 2 above), but excludes the schema (https:// and the port (implicit 443) in both examples above) as defined by RFC for the URL:

http_URL = "http(s):" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Uniform Resource Identifiers

By RFC URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers, and finally the combination of Uniform Resource Locators (URL). As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify–via name, location, or any other characteristic–a resource.

Further Sources:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2
http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri