[solved] openlitespeed: Return 404 when a php file is requested

Discussion in 'Install/Configuration' started by steve81, Jul 8, 2013.

  1. steve81

    steve81 New Member

    Hello, I'm having some trouble in a simple (at least I think so) rewrite rule: I want to return 404 for all php files.

    But I should also take in care that they can have a path info (so something like http://www.example.com/foo.php/bar) or that a path can have .php (e.g.: http://www.example.com/foo.php/bar.jpg where foo.php is a directory and this should not be blocked).

    I've noticed that, on apache, I can easily do that using ${LA-U:REQUEST_FILENAME} but (open)litespeed doesn't support it.

    How I can do that in litespeed? Even without rewrite rules, ofc.

    Regards.
    Last edited by a moderator: Jul 13, 2013
  2. NiteWave

    NiteWave Administrator

    in the case you described, just

    RewriteRule /.*.php$ /err404.html [L]

    will do.

    /err404.html can be a non-exist file.

    tested on openlitespeed 1.2
  3. steve81

    steve81 New Member

    I don't know how much openlitespeed changed from v1.0.4 to v1.2, but with your rewrite rule an url like http://www.example.com/index.php?/foo showed to me the php file (instead of 404).
    Maybe I miss some points.
  4. NiteWave

    NiteWave Administrator

    Sorry, re-tested on open lsws 1.2
    with

    RewriteRule /.*.php$ /err404.html [L]

    show "500 Internal Server Error"
    in error.log:
    2013-07-08 07:25:27.248 [INFO] [ip:49485:SPDY3-3] [REWRITE] Source URI: '/test.php/bbb.php' => Result URI: '/error404.html'
    2013-07-08 07:25:27.248 [INFO] [ip:49485:SPDY3-3] [REWRITE] Last Rule, stop!
    2013-07-08 07:25:27.248 [ERROR] [ip:49485:SPDY3-3] detect loop redirection.

    but this should not be loop redirection.

    right, looks bug here.
  5. steve81

    steve81 New Member

    Excuse me, but my example wasn't ending in php; that's the difference (i suppose).

    My use case, actually, is:

    Thank you for your time.

    Regards.
  6. NiteWave

    NiteWave Administrator

    following rules can pass through all your patterns:

    RewriteCond %{REQUEST_FILENAME} \.php$ [OR]
    RewriteCond %{SCRIPT_NAME} \.php$
    RewriteRule /(.*) /error404.html [L,R=404]

    /error404.html must exist.
    otherwise may cause the "loop redirection" issue in openls.
    (tested on openls 1.2)
  7. steve81

    steve81 New Member

    Thanks, nearly perfect. Doesn't still pass one precondition: "if foo.php is a file".

    I tried to add a -f, but I don't understand the OR / AND precedence.

    I think that I should do something like this:
    A) RewriteCond %{REQUEST_FILENAME} -f
    B) RewriteCond %{REQUEST_FILENAME} \.php$
    C) RewriteCond %{SCRIPT_NAME} \.php$

    How I can chain those rule as "( A and B ) or C"? The only way is to do "(A or C ) and ( B or C )"?

    ---

    While ${SCRIPT_NAME} trim out the path info and give to me the ${SCRIPT_NAME} related to the www root, I noticed that ${SCRIPT_FILENAME} doesn't trim out the path info; actually, seems to me, that act like ${REQUEST_FILENAME}.

    So, with an url like http://www.example.com/foo.php/bar:
    ${SCRIPT_NAME} = /foo.php
    ${SCRIPT_FILENAME} = /path/to/www/root/foo.php/bar

    Can I suppose that is an error? AFAIK the difference between SCRIPT_NAME and SCRIPT_FILENAME should be only the base path.

    Also I noticed that, on url without a query, SCRIPT_(FILE)NAME is not set. SCRIPT_(FILE)NAME will not be set every time the called URL should be processed by a CGI/LSAPI/FASTCGI process?

    Regards,
    Stefano
    Last edited: Jul 10, 2013
  8. NiteWave

    NiteWave Administrator

    default is AND.
    A)
    B) [OR]
    C)
    ==>( A and B ) or C
    this is apache rule, litespeed or open litespeed will follow it. if not, it's bug.
  9. steve81

    steve81 New Member

    So, it's a bug:
    2013-07-10 10:42:23.750 [INFO] [] [REWRITE] Rule: Match '/index.php/foo' with pattern '/.*', result: 1
    2013-07-10 10:42:23.750 [INFO] [] [REWRITE] Cond: Match '/var/www/some/path/htdocs/index.php/foo' with pattern '\.php$', result: -1

    and here it stop.

    using those rules:
    RewriteCond %{REQUEST_FILENAME} \.php$
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{SCRIPT_NAME} \.php$
    RewriteRule /.* /notexist.html [L,R=404]





    What about the SCRIPT_FILENAME issue? Is correct current* behaviour?

    I really appreciate your support.

    *I'm using the stable branch, so with "current" I mean v1.0.4.
  10. NiteWave

    NiteWave Administrator

    I got same result with you on open ls 1.2
    it acts like [OR] is ignored.

    tested on lsws 4.2.3, the result is expected.

    however, this simpler version:
    RewriteCond %{SCRIPT_NAME} \.php$
    RewriteRule /(.*)$ /notexist.html [L,R=404]

    works under open ls (1.0.4 and 1.2 may have no difference here)
    and just what you want.

    please confirm at your 1.0.4 env.

    just tested SCRIPT_NAME and SCRIPT_FILENAME
    for /foo.php/bar on open ls 1.2, the result is

    this is foo.php
    $_SERVER["SCRIPT_NAME"]=/foo.php
    $_SERVER["SCRIPT_FILENAME"]=/path/to/foo.php

    as expected. source code:
    PHP:
    <?php
    echo "this is foo.php<br>";
    echo 
    "\$_SERVER[\"SCRIPT_NAME\"]=" $_SERVER["SCRIPT_NAME"]."<br>";
    echo 
    "\$_SERVER[\"SCRIPT_FILENAME\"]=" $_SERVER["SCRIPT_FILENAME"]."<br>";
    ?>
  11. steve81

    steve81 New Member

    RewriteCond %{SCRIPT_NAME} \.php$
    RewriteRule /(.*)$ /notexist.html [L,R=404]

    Doesn't work under 1.0.4:

    the script, however, report always the right values. Seems that during the rewrite the variables have wrong values (or different or empty).
  12. NiteWave

    NiteWave Administrator

    Sorry again.
    re-tested under open ls 1.2 and lsws 4.2.3.
    same result with you for open ls 1.2 and 1.0.4

    RewriteCond %{SCRIPT_NAME} \.php$
    RewriteRule /(.*)$ /notexist.html [L,R=404]

    working perfectly under 4.2.3 (you can try 4.2.3 standard version if possible)
    it seems open ls 1.0.4 or 1.2 just don't understand %{SCRIPT_NAME} in RewriteCond.

    that can explain the test result on open ls 1.x

    I'll submit bugs found from this thread.
  13. steve81

    steve81 New Member

    Thank you, I've tested the 1.2.2 and works.

    I've made an extra test and I noticed that, if I set a php as index file, it avoid the script_name rule. Shouldn't the SCRIPT_NAME (or SCRIPT_FILENAME) even when the file is the index file of a directory?

    In my use case isn't usefull, but with other rewrite rule can be mandatory.

    Regards and thanks again.
  14. NiteWave

    NiteWave Administrator

    I've not tested with open ls 1.2.2 yet ... but looks like it's updating fast, so feel free to find and submit more bug reports!

    tested on 4.2.3, same result, it should be ideal to block it.

    record the test result here:
    index.php is the index file
    RewriteCond %{SCRIPT_NAME} \.php$
    RewriteRule /(.*)$ /my404.html [L,R=404]

    127.0.0.1:8088/
    200 OK
    in error.log, just this line:
    2013-07-12 22:13:31.519 [INFO] [ip:51139-0#Example] [REWRITE] Rule: Match '/' with pattern '/(.*)$', result: 2

    127.0.0.1:8088/index.php
    404 Not Found

    will look if possible any improvement on this case and more detail log.

Share This Page