httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 38642] mod_rewrite adds path info postfix after a substitution occured
Date Tue, 25 Nov 2008 20:49:57 GMT

--- Comment #17 from Bob Ionescu <>  2008-11-25 12:49:56 PST
(In reply to comment #16)
> (In reply to comment #13)
> > I thought that since this is per-directory, PT-like behavior is implied so
> > whenever we change the filename and re-inject into apache, so PATH_INFO is very
> > soon to be "fixed" by the core.
> > 
> > The only time it lasts longer is when we have another rule or two to look at
> > before re-injecting.
> I could be wrong, but the way I understand it, PATH_INFO is just derived from
> the original URL - before any rewriting occurs. And is never "fixed".

Yes, derived from the physical filename after the request has been mapped to
the file system. I think Eric meant that it is fixed in the redirect processing
(new file system mapping, new path info for the internal redirect processing).

I think erasing path_info is not a good idea. Even if it seems to be useless
(since you can check the URL-path), someone (either content handlers or e.g.
RewriteConditions) may relay on that ENV. That's why I've chosen to leave it
untouched but prevent further appending if a substitution occurred.

I cannot imagine a case where "not appending path_info after a subst. was
applied but leaving r->path_info untouched" can break any case – either at
server/rewrite rule side nor at script side. No one uses a construct of rewrite
rules, which expects continuing appending of path_info – and I've seen a lot
of rules in a german discussion forum about mod_rewrite. It's the opposite.
There were questions "what went wrong" when it comes to the behavior described
in this PR.

(In reply to comment #10)
> I would however check perdir *before* making each calls to apr_table_xxx, as
> these calls are relatively slow.

As I wrote – rush.  :-) I think most calls were made in sections which are
touched by the fix-up hook (i.e. directory context) only. May be a check for
path_info != NULL would be better.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message