Yesterday I discovered that my server's response to non-supported HTTP methods was incorrect. If an HTTP method is not supported you're supposed to respond with an HTTP 405: Method Not Supported. Pandurang was able to answer that question.
I've done a lot of reading about how [L] loops and I had spent time going through all the Apache 2.4 flag documentation.
I tried using the [L] flag and then the [END] flag.
I tried to combine flags in every possible way (e.g. [L,R=405], [END,R=405]) on both RewriteRule sets.
I tried combinations where flags where absent.
I rearranged the order of the rules.
I tried adding RewriteCond %{REQUEST_METHOD} ^(GET|POST)$ before the unrelated second RewriteRule.
I did a lot of reading.
Here are the two set of rules:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST)$
RewriteRule .* - [R=405]
#Unrelated rule, when present, breaks the above HTTP 405 turning it in to an HTTP 302:
RewriteRule !\.(css|js|zip)$ index.php [L]
To do testing I ran the following command using cURL:
curl -X PUT -d arg=val -d arg2=val2 https://www.example.com/ -i
I know the HTTP 405 code works via cURL because I can see the response code, just not when the other line is present and I have to have both. What do I need to do to force Apache to stop looping/processing once it matches a rule?
For some reason the new code must be at the bottom, which makes no sense as I'd like to avoid having Apache process all of the other rules to only end up doing this.
#Unrelated rule
RewriteRule !\.(css|js|zip)$ index.php [L]
#Rule that now works, only at the bottom
RewriteCond %{REQUEST_METHOD} !^(GET|POST)
RewriteRule .* - [R=405,L]
Related
I have a website using MODx Revolution (2.2.10-pl, advanced install), let's call it www.example.com, which I want to be accessible with both http and https.
to achieve this, I tweaked the site_url context setting to be [[++url_scheme]]www.example.com/. Links created using [[~id]] seem to be alright, however, sometimes, the generated links are really weird. My interpretation is that the code to create links programmatically doesn't work with my settings, but I don't know why, or how else I would go about enabling both http and https.
Question first, examples below: How should I set the site_url or any other site/context setting so that links on my site work with both http and https? Optionally, is the behavior I see a bug, or expected behavior given Revolution's tag evaluation semantics?
Misbehavior examples:
When I click on "View" in the manager for a resource with the alias example, the address that is opened is
https://www.example.com/xyz/[[++url_scheme]]www.example.com/example/
where xyz is my manager URL. The expected URL is of course
https://www.example.com/example/
Another case where this happens is for failed logins; my login call looks like this (minus irrelevant parts):
[[!Login? &redirectToOnFailedAuth=`[[++unauthorized_page]]`]]
The unauthorized_page's expected full URL is
https://www.example.com/special/401
but the URL which is opened for a failed login as username is
https://www.example.com/[[++url_scheme]]www.example.com/[[++url_scheme]]www.example.com/special/401?u=username
The second example is the same for http, except for the scheme, of course; I haven't logged into the manager with http.
EDIT
.htaccess at the webroot:
RewriteEngine On
RewriteBase /
# redirect all requests to /en/favicon.ico to /favicon.ico
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en)/favicon.ico$ favicon.ico [L,QSA]
#RewriteRule ^(en|nl|de)/favicon.ico$ favicon.ico [L,QSA]
# redirect all requests to /en/assets* /assets*
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en)/assets(.*)$ assets$2 [L,QSA]
#RewriteRule ^(en|nl|de)/assets(.*)$ assets$2 [L,QSA]
# redirect all other requests to /en/*
# to index.php and set the cultureKey parameter
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(en)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
#RewriteRule ^(en|nl|de)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
.htaccess in the manager's directory:
RewriteEngine On
RewriteBase /
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/xyz/$1
The problem is with $modx->makeUrl(). For example, for the
[[!Login? &redirectToOnFailedAuth=`[[++unauthorized_page]]`]]
call, in core/components/login/controllers/web/Login.php:
public function checkForRedirectOnFailedAuth(modProcessorResponse $response) {
$redirectToOnFailedAuth = $this->getProperty('redirectToOnFailedAuth',false,'isset');
if ($redirectToOnFailedAuth && $redirectToOnFailedAuth != $this->modx->resource->get('id')) {
$p = array(
'u' => $this->dictionary->get('username'),
);
$message = $response->getMessage();
if (!empty($message)) $params['m'] = $message;
$url = $this->modx->makeUrl($redirectToOnFailedAuth,'',$p,'full');
$this->modx->sendRedirect($url);
}
}
the last two lines do a redirect to a URL generated with makeUrl, which will be something like [[++url_scheme]]www.example.com/etc (note: I'm not 100% sure here, as I can't easily look at the raw URL. The conclusions still hold, though). If the URL is simply shown on the page, this is no problem, because MODx will parse the tag before inserting it into the html output. However, as the URL is used directly for the redirect, no such replacement takes place, and the browser interprets it as a relative URL, resulting in target URLs such as https://www.example.com/[[++url_scheme]]www.example.com/etc.
So much for the problem. To avoid this, site_url must be a literal value without any tags in it. As a workaround, I now use the following snippet as the first thing in my template:
$modx->config['site_url'] = $modx->config['url_scheme'] . substr($modx->config['site_url'], strlen('[[++url_scheme]]'));
return '';
together with a [[++site_url]] of
[[++url_scheme]]www.example.com/
Note that some parts of MODx don't seem to notice this update, which is why it's important to still use [[++url_scheme]] in your site_url. As far as I can tell right now, the parts that don't see the update, stuff like [[~id]], work properly with url_scheme.
EDIT this does of course only fix the "View" buttons in the manager if you tweak the manager templates accordingly.
WARNING this is of course very hacky, and not yet tested very well. The fact that some features do not see the overwritten value means that you're introducing an inconsistency into your website, which may lead to subtle errors! If a more clean solution comes up, go for it!
Here are my current rules:
RewriteCond %{QUERY_STRING} ^to=(one|seventeen|thirty\+four)
RewriteRule ^/folder/page.php$ http://www.site.com/folder/category/%1? [L]
RewriteRule ^folder/category/(.+)\+(.+)$ http://www.site.com/folder/category/$1-$2 [L]
The first rule works fine, it redirects perfectly if the word is in the query string, but I can't get thirty+four to become thirty-four when redirected.
Any help would be greatly appreciated.
For starters, RewriteRule ^/folder/page.php$ will never match anything. The URI's get the prefix (the leading slash) removed if the rules are in an .htaccess file instead of server config.
Secondly, since you've included http://www.site.com/ in your targets, that means the browser will get redirected instead of internally rewritten. You need to remove http://www.site.com/ from your first rule so that the second one can be applied.
Here's what should work:
RewriteCond %{QUERY_STRING} ^to=(one|seventeen|thirty\+four)
RewriteRule ^folder/page.php$ folder/category/%1 [NC,QSA,L]
RewriteRule ^folder/category/(.+)\+(.+)$ folder/category/$1-$2 [NC,QSA,L]
And now three hints:
1)
Please make sure you've read everything here before asking:
Here's the wiki of serverfault.com
The howto's htaccess official guide
The official mod_rewrite guide
2)
Please try to use the RewriteLog directive: it helps you to track down problems:
# Trace:
# (!) file gets big quickly, remove in prod environments:
RewriteLog "/web/logs/mywebsite.rewrite.log"
RewriteLogLevel 9
RewriteEngine On
3)
My favorite tool to check for regexp:
http://www.quanetic.com/Regex (don't forget to choose ereg(POSIX) instead of preg(PCRE)!)
You use this tool when you want to check the URL and see if they're valid or not.
I have two domains that are aliases, domain1.com and domain2.com
Currently they are both directed into the same place, the root of my web space. However, I wish to separate them into independent pages and direct domain2.com into a subfolder with different content.
I understand that the correct way to do this is using Apache Virtual Hosts. However, my service provider does not allow me access to that functionality so I'll have to solve it using mod_rewrite.
What I need is something that directs www.domain2.com and domain2.com to subfolder/ (which should trigger index.php). Also, www.domain2.com/file.txt should go to subfolder/file.txt, etc... This is what I came up with:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} domain2\.com [NC]
RewriteRule ^(.*)$ subfolder/$1 [L]
</IfModule>
However, when I run it and go to domain2.com, I get 500 Internal Server Error and the log file says:
Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
To test what's going on I made a small php script that prints out the string that it gets.
I also modified the rule:
RewriteRule ^(.*)$ subfolder/test.php?string=$1 [L]
Now when I go to domain2.com or domain2.com/asd, it prints out: subfolder/test.php
Somehow it gets into recursion and prints itself. Whereas, if I use the following rule:
RewriteRule ^abc(.*)$ subfolder/test.php?string=$1 [L]
Then domain2.com/abcdef prints: def
I can't figure out what I'm doing wrong. Do you have any suggestions?
Thanks!
It could be that the rewrite rule applies to subfolders of the one whose .htaccess it appears in. Does it help to add a condition that blocks the rewrite for URLs that already start with subfolder/?
I have a CI application that uses .htaccess for URL routing. My basic setup is as follow:
RewriteRule ^$ /var/www/html/ferdy/jungledragon/index.php [L]
RewriteCond $1 !^(index\.php|images|img|css|js|swf|type|themes|robots\.txt|favicon\.ico|sitemap\.xml)
RewriteRule ^(.*)$ /var/www/html/ferdy/jungledragon/index.php/$1 [L]
These rules are pretty standard for CI apps. They rewrite all URLs (except for those in the exception list) to the index.php front controller. The lines above also hide index.php, as it would normally appear as part of every URL.
So far, so good. Everything works just fine. Now, for the sake of SEO I would like to force all traffic to www. So I extended the rules as follow:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^$ /var/www/html/ferdy/jungledragon/index.php [L]
RewriteCond $1 !^(index\.php|images|img|css|js|swf|type|themes|robots\.txt|favicon\.ico|sitemap\.xml)
RewriteRule ^(.*)$ /var/www/html/ferdy/jungledragon/index.php/$1 [L]
rewritecond %{http_host} ^jungledragon.com [nc]
rewriterule ^(.*)$ http://www.jungledragon.com/$1 [r=301,nc]
These last two lines rewrite http://jungledragon.com/anything URLs to http://www.jungledragon.com/anything URLs. This kind of works, but it brings back the index.php part back: http://jungledragon.com/anything becomes http://www.jungledragon.com/index.php/anything.
How exactly do I combine these rules so that they do not interfere with each other? I tried doing the WWW rewrite before the CI rules. That shows an Apache 301 page with an error, rather than doing the actual redirect.
Additionally, I would like to also include rules to get rid of trailing slashes, but for now let's keep the question simple. Note that I did find useful post here and elsewhere yet for some reason I still can't find the correct exact syntax for my situation.
Edit: Thanks for the help. This works:
Options +FollowSymlinks
RewriteEngine on
rewritecond %{http_host} ^jungledragon.com [nc]
rewriterule ^(.*)$ http://www.jungledragon.com/$1 [r=301,nc,L]
RewriteRule ^$ /var/www/html/ferdy/jungledragon/index.php [L]
RewriteCond $1 !^(index\.php|images|img|css|js|swf|type|themes|robots\.txt|favicon\.ico|sitemap\.xml)
RewriteRule ^(.*)$ /var/www/html/ferdy/jungledragon/index.php/$1 [L]
mod_rewrite processes rules in a linear fashion. Rules at the top of the file are processed first.
The [nc] and [L] at the end of the rules are the options for how to process rules.
nc - nocase: case insensative
L - last: last rule in the execution (if you hit this, stop processing)
You need to put your www redirect rules above your CI rules so it will first add the www, THEN apply the CI rules to the newly re-written url. **And also use either the C or N flag with your www redirect rule so it will parse the next rule.
http://mysite.com/blah ==becomes==> http://www.mysite.com/blah ==becomes==> http://www.mysite.com/index.php/blah (Executed, not redirected)
What's happening currently is:
http://mysite.com/blah ==becomes==> http://mysite.com/index.php/blah (STOP)
Browser goes to http://mysite.com/index.php/blah and a second re-write pass is done since your exceptions stop /index.php urls from being processed
http://mysite.com/index.php/blah ==becomes==> http://www.mysite.com/index.php/blah (Redirected)
As Suggested, here is a link to mod_rewrite's documentation if you want to look further.
#LazyOne: Brainfart, sorry.
Here's an excerpt from the docs outlining the flags you'll probably need:
'chain|C' (chained with next rule)
This flag chains the current rule with the next rule (which itself can be chained with the following rule, and so on). This has the following effect: if a rule matches, then processing continues as usual - the flag has no effect. If the rule does not match, then all following chained rules are skipped. For instance, it can be used to remove the .www'' part, inside a per-directory rule set, when you let an external redirect happen (where the.www'' part should not occur!).
'next|N' (next round)
Re-run the rewriting process (starting again with the first rewriting rule). This time, the URL to match is no longer the original URL, but rather the URL returned by the last rewriting rule. This corresponds to the Perl next command or the continue command in C. Use this flag to restart the rewriting process - to immediately go to the top of the loop.
Be careful not to create an infinite loop!
'nocase|NC' (no case)
This makes the Pattern case-insensitive, ignoring difference between 'A-Z' and 'a-z' when Pattern is matched against the current URL.
'noescape|NE' (no URI escaping of output)
This flag prevents mod_rewrite from applying the usual URI escaping rules to the result of a rewrite. Ordinarily, special characters (such as '%', '$', ';', and so on) will be escaped into their hexcode equivalents ('%25', '%24', and '%3B', respectively); this flag prevents this from happening. This allows percent symbols to appear in the output, as in
I'm trying to do something pretty simple in iirf.
I want all requests that are missing the www. prefix to have it added.
This is my IsapiRewrite4.ini:
RewriteCond %{HTTP_HOST} ^example\.com$ [I]
RewriteRule ^(.*)$ www.example.com/$1 [R=301,L]
This is my SampleUrls.txt:
example.com
example.com/grants
www.example.com
www.example.com/grants
I place the files in the same directory as TestDriver.exe, and run testdriver -d .
All the tests are ignored:
NO ACTION 'example.com' ==> --
NO ACTION 'example.com/grants' ==> --
NO ACTION 'www. example.com' ==> --
NO ACTION 'www. example.com/grants' ==> --
Thanks,
Ashley
The TestDriver is a standalone tool to test rewrite rules for IIRF. Unfortunately, the tool is limited, in that it cannot effectively evaluate conditions that test Server variables. There are no server variables in a standalone console-based application.
Check the doc. Here's what it says:
Please note: the TestDriver.exe program is a useful testing tool, but it does not and cannot replace actual testing in the context of a web server. The testdriver does not run within the context of an HTTP server, and so does not work with HTTP Server variables. In particular, if you use RewriteCond in the ini files that you test with TestDriver.exe, and those RewriteCond statements reference Server variables (eg %{HTTP_URL} or %{HTTP_REFERER}) , those RewriteCond statements will not behave in the TestDriver the same way they will behave in an ISAPI. Tests of such conditions will not be useful in verifying actual operational performance.
You need to specify an absolute URL for the substitution. Otherwise your www.example.com is treated as path segment.
RewriteCond %{HTTP_HOST} ^example\.com$ [I]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]