Project

General

Profile

Bug #1819

mod_rewrite not working anymore after patching

Added by djanov about 9 years ago. Updated almost 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2008-11-11
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

After patching with lighttpd-1.4.x_rewrite_redirect_decode_url.patch this rule doesnt seem to work :

url.rewrite-once = (
some other rules
"^/cat/p/(.*)/t/(.*)/g/(.*)/a/(.*)/o/(.*)/t/(.*)/d/(.*)" => "/catalog.php?p=$1&title=$2&genre=$3&actor=$4&ord=$5&type=$6&director=$7",
"^/cat/p/(.*)/t/(.*)/g/(.*)/a/(.*)/o/(.*)/t/(.*)" => "/catalog.php?p=$1&title=$2&genre=$3&actor=$4&ord=$5&type=$6",
"^/cat/p/(.*)/t/(.*)/g/(.*)/a/(.*)/o/(.*)" => "/catalog.php?p=$1&title=$2&genre=$3&actor=$4&ord=$5",
"^/cat/p/(.*)/t/(.*)/g/(.*)/a/(.*)" => "/catalog.php?p=$1&title=$2&genre=$3&actor=$4",
"^/cat/p/(.*)/t/(.*)/g/(.*)" => "/catalog.php?p=$1&title=$2&genre=$3",
"^/cat/p/(.*)/t/(.*)" => "/catalog.php?p=$1&title=$2",
"^/cat/p/(.*)" => "/catalog.php?p=$1",
some other rules
)

Before patching the first rule that lighttpd took and "execute" was the first in line aka :

"^/cat/p/(.*)/t/(.*)/g/(.*)/a/(.*)/o/(.*)/t/(.*)/d/(.*)" => "/catalog.php?p=$1&title=$2&genre=$3&actor=$4&ord=$5&type=$6&director=$7",

Now lighttpd takes for first rule :

 "^/cat/p/(.*)" => "/catalog.php?p=$1", 

Which totally breaks the script functionality because the passed variables as genres etc.etc. get passed as catalog.php?p=$something , but not as /catalog.php?p=$1&title=$2&genre=$3&actor=$4&ord=$5&type=$6&director=$7

Please fix this , i have to go back to an older lighty for my scripts to work for now


Related issues

Related to Bug #1720: Rewrite/redirect rules and URL encodingNeed Feedback

Is duplicate of Bug #1827: 400 Response on any URL that countains a space character (ASCII 20)Fixed2008-11-20

History

#1

Updated by stbuehler almost 9 years ago

  • Priority changed from High to Normal

Missing the concrete url which failed; but i guess there is some proxying involved.
Apart from that, the application should handle such complex rewrites, not the webserver (so it is portable).

Anyway, we will probably revert that "security" fix and advise all users not to use rewrites to protect files.

#2

Updated by icy almost 9 years ago

  • Status changed from New to Fixed

Should be fixed in r2362

Also available in: Atom