https://issues.apache.org/bugzilla/show_bug.cgi?id=38642
--- Comment #17 from Bob Ionescu <[EMAIL PROTECTED]> 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: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
