php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #81670 Access log contains wrong values for "%r" (request URI) format string
Submitted: 2021-11-28 18:55 UTC Modified: 2021-11-29 20:53 UTC
From: amenshchikov at gmail dot com Assigned: bukka (profile)
Status: Assigned Package: FPM related
PHP Version: 8.1.0 OS: Debian 11
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2021-11-28 18:55 UTC] amenshchikov at gmail dot com
Description:
------------
Instead of real request URI (without query string), that contained in REQUEST_URI env variable, "%r" outputs SCRIPT_NAME value into access log.

In case I need request URI with query string, I can use "%{REQUEST_URI}e" and there is no problem. But when I need request URI without query string (as it intended with "%r") I don't know what to do.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-11-28 19:32 UTC] bukka@php.net
FPM takes request URI from the SCRIPT_NAME. I guess this is more a documentation issue (more description in docs maybe) / feature request so I will change this to feature request as we can't just change it at this stage anyway.
 [2021-11-28 19:32 UTC] bukka@php.net
-Type: Bug +Type: Feature/Change Request -Assigned To: +Assigned To: bukka
 [2021-11-28 19:52 UTC] bukka@php.net
I assume that you really want to be able to log path info, right?
 [2021-11-28 20:06 UTC] ameshchikov at gmail dot com
Yes, you are right.

And honestly, I don't think that there is a documentation issue.
As I can see, access.format has dedicated placeholder "%f" for script_filename and it seems strange to use "%r" just for script_name (without full path to that script). It seems like "%r" intended to contain certainly request URI (or path info).
 [2021-11-29 20:53 UTC] bukka@php.net
What I meant that we should update documentation to state that "%r" is for SCRIPT_NAME rather than for REQUEST_URI fcgi env. We cannot just change the value as it could potentially break some scripts that already depend on it being a SCRIPT_NAME. The thing is that internally script name is taken as request uri so I don't think REQUEST_URI is used for anything but might have missed something.

In your case it doesn't really matter that much because if we just changed it to REQUEST_URI than it would contain a query so I guess it wouldn't help you. I guess specific flag for path info might help as it might not be always reliable to get it from env (at least the logic around that doesn't seem that straight forward as there are some hacks around Apache). You might actually give it a try and see if "%{PATH_INFO}e" or "%{ORIG_PATH_INFO}e" works for you?
 [2021-11-29 22:17 UTC] amenshchikov at gmail dot com
"%{PATH_INFO}e" produces empty string, "%{ORIG_PATH_INFO}e" produces "-".

I have the following nginx configuration:

server {
    ...
    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/index\.php(/|$) {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;

        include fastcgi.conf;
        internal;
    }
    ...
}
 [2021-12-01 06:58 UTC] amenshchikov at gmail dot com
Another one place where the same problem takes place — status page.
There "request URI" also shows the SCRIPT_NAME (with query string) instead of REQUEST_URI (see https://bugs.php.net/bug.php?id=72319).
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Jan 29 14:03:34 2022 UTC