Skip to content
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

PATH_INFO is not ignored, as generally done by Apache for static #14

poeml opened this issue Jun 5, 2015 · 0 comments

PATH_INFO is not ignored, as generally done by Apache for static #14

poeml opened this issue Jun 5, 2015 · 0 comments


Copy link

@poeml poeml commented Jun 5, 2015

                                                                                                      [          ]

Issue migrated (2015-06-05) from old issue tracker

Title    PATH_INFO is not ignored, as generally done by Apache for static
 Priority   bug                       Status           resolved
Superseder                          Nosy List          poeml
Assigned To poeml                    Keywords

msg43 (view) Author: poeml Date: 2009-10-26.22:10:18

Here's a report from the openSUSE bugzilla:

Description From Matt Barringer 2009-10-13 02:31:27 MDT (-) [reply]

A URL like
returns the RPM rather than returning a 404 error. This causes some bad
problems for SUSE Studio when users add build service repositories by URL.

------ Comment #2 From Matt Barringer 2009-10-26 12:19:19 MDT (-) [reply] -------
Is there a reason to not treat the RPM URLs as files, rather than as a CGI
script? I don't really understand why PATH_INFO would be useful here.

------- Comment #3 From Peter Poeml 2009-10-26 15:12:27 MDT (-) [reply] -------
The behaviour is indeed different than when you would request a static file
from Apache.

The debug log (where r is the request context that Apache gives my module)

  debugLog(r, cfg, "URI: '%s'", r->unparsed_uri);
  debugLog(r, cfg, "filename: '%s'", r->filename);

logs the following for a request on .../foo/bar:

[Mon Oct 26 21:49:14 2009] [warn] [client] [mod_mirrorbrain] URI:
[Mon Oct 26 21:49:14 2009] [warn] [client] [mod_mirrorbrain]

The documentation
( enlightens us:

The core handler for normal files defaults to rejecting PATH_INFO requests. Handlers that serve scripts, such as cgi-script and isapi-handler, generally accept PATH_INFO by default.

mod_mirrorbrain is not a script, but it runs a handler similar to a script.

If it makes sense, the behaviour could be changed. What is the motivation? What
kind of funny requests are causing the problem?

(For the record, AcceptPathInfo Off in the context of the MirrorBrain config
has the desired effect as well)

msg185 (view) Author: poeml Date: 2010-04-23.03:27:46

I committed a fix to the trunk. It'll appear in the next release, which I'll hopefully complete during
the next weeks.

With the following patch, requests with PATH_INFO correctly lead to 404s, unless the server is
configured explicitely to allow PATH_INFO. This follows the best practice that modules should respect
the default.

mod_mirrorbrain now no longer (falsely) behaves like mod_cgi*.

--- mod_mirrorbrain.c (revision 8042)
+++ mod_mirrorbrain.c (working copy)
@@ -1092,6 +1092,12 @@
return DECLINED;

  • /* is there PATH_INFO, and are we supposed to accept it? */

  • if ((r->path_info && *r->path_info)

  •        && (r->used_path_info != AP_REQ_ACCEPT_PATH_INFO)) {
  •    debugLog(r, cfg, "ignoring request with PATH_INFO");
  •    return DECLINED;
  • }

    debugLog(r, cfg, "URI: '%s'", r->unparsed_uri);
    debugLog(r, cfg, "filename: '%s'", r->filename);

msg186 (view) Author: poeml Date: 2010-04-23.03:31:01

msg222 (view) Author: poeml Date: 2010-09-06.00:01:52

I haven't received feedback about the effectivness of the bug yet; but I'm closing
this issue as resolved nevertheless. Please reopen if necessary.

         Date         User  Action              Args
2010-09-06 00:01:52 poeml set    status: testing -> resolved
                                   messages: + msg222
2010-04-23 03:31:01 poeml set    messages: + msg186
2010-04-23 03:27:46 poeml set    status: in-progress -> testing
                                   messages: + msg185
2010-02-10 04:43:26 poeml set    status: unread -> in-progress
2009-10-26 22:10:19 poeml create

(end of migrated issue)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant