Yes,
The problem was unrelated to LS - it was because I was testing in a browser, and the page I was trying to redirect to hasn't been created yet. I tried using curl, and it worked as expected.
Sorry to have taken up your time. Thanks for your help.
Marcus.
Hi,
I'm trying to do an external rewrite like :
http://example.com/example_url => http://other.server.com/http://example.com/example_url
The rewrite rule I have tried is :
RewriteRule .* http://other.server.com/http://%{SERVER_NAME}%{REQUEST_URI} [R,L]
but this just hangs. The...
Hi,
At the server level, I added the following entry into the Apache-style settings:
php_value open_basedir "$VH_ROOT/public:$VH_ROOT/includes"
The resulting open_basedir value though held the server's prefix not the $VH_ROOT. If I add this entry at the template level, it works as...
I fully understand that one of your aims is to be Apache-interchangeable, and if Apache follows the same method regarding directories, then it is sensible for you to stay with your current approach. Also, I understand you won't want to change things if it is likely/possible to cause problems...
I feel that /login/password.shtml shouldn't be mapped to /login, but it should be mapped to /login/ and exp:^/login (or any other sensible regexes).
I just checked, and see that if you don't specify a location for regexes and if the specified location doesn't exist at the time of loading the...
I didn't realise you needed to specify the location as a file. It doesn't seem right to me that I should have to, though. It should be purely on the basis of the URL (IMHO).
If you say that the following are true
- /login matches exactly the URL /login and nothing else (though maybe...
The context is defined as 'static'.
Eventually it will point to a file, but I want to use the 'nice' URL of /login rather than /login.php or something like that.
There is a directory /login/, but that just contains the SHTML files. I therefore can't point /login directly to a file...
Regex contexts also don't seem to work
I've created a context
exp:^/admin
but the rewrite rules inside this context also don't seem to be being processed at all, though if they're defined at the VHOST level they are.
What about having multiple versions of your standard/enterprise servers, both with and without largefile support? That way, if a user needs it, then they can have it, but if they don't, they won't suffer the extra overhead.
The rewrite rules for for context /login are:
RewriteCond %{HTTP_COOKIE} lang=(en|fr|tr)
RewriteRule ^(.*)$ $1/%1.shtml [L,NE]
RewriteRule ^(.*)$ $1/en.shtml [L,NE]
and the full log entries are:
2009-01-09 06:20:08.174 [INFO]...
Any idea of timeframe for implementing an ISAPI or LSAPI-ISAPI bridge? I think it could be a really useful feature, especially for the larger websites.
Hi,
I have defined a context /login, with some settings and rewrite rules inside. When I try to access the page at
http://mysite.com/login
the URL is checked in the rewrite rules at the VHOST level, but not the context level. A redirection is then sent to
http://mysite.com/login/...
That problem appears to have been fixed in the latest binary version (at least basic restarts have). I won't go through all the process I did before, but if I experience any more issues, I'll post them.
I've downloaded the latest binary, and all is well.
I didn't realise that binaries of the same name might be different. If you're going to do that, have you thought of adding some additional numbering
e.g. 4.0b3.1, 4.0b3.2...
Do the production versions also sometimes differ in between...
In the logs, there are these entries
2009-01-08 04:44:39.556 [INFO] [127.0.0.1:36632-0#simpl-ssl] [REWRITE] Rule: Match '/admin&lang=en' with pattern '^/admin(.*)$', result: 2
2009-01-08 04:44:39.556 [INFO] [127.0.0.1:36632-0#simpl-ssl] [REWRITE] Source URI: '/admin&lang=en' => Result URI...
I have the following situation:
- a web server defined in the config with the name 'besvr', which is open on port 8000
- the following rewrite rule:
RewriteRule ^/admin(.*)$ http://besvr/admin$1 [NE,L,P]
With the aim of proxying anything beginning with /admin to the backend...