This is the default behavior when the target is a fully qualified URL i. One final remark about this example is necessary, before we move on to discuss other map types. The rule itself is written to work in your main Apache configuration file httpd. Specifically, if this rule is placed in an. RewriteMap cannot go in. Randomized Rewrites The next type of map, the rnd: map, allows for a result to be randomly selected from a list of several possible options. The idea here is that we have defined two groups of servers.
The other server will be used to serve the dynamically generated URLs. This allows us to have several low-end servers to serve the static files and then our high-powered servers to do the heavy lifting. The next two lines rewrite all requests so that requests are proxied through to one of the two server pools. Requests ending in. All other requests are proxied to a server from the other pool. For example, if you wanted the main site front page, index.
If one of the servers in the rotation is twice as powerful as the others, you may wish for it to get more of the requests than the other server. This can be accomplished by putting that server in the list more frequently: dynamic venus mercury neptune pluto pluto In the preceding entry from the servermap.
Similarly, if one of the servers is down for maintenance and thus needs to be taken out of the rotation, you need only remove its name from the servermap. This allows for servers to be added to and removed from the server pool in a completely transparent fashion. The rnd: rewrite technique can also be used for other random things, such as displaying a random image in a web page.
In your HTML, we can refer to a particular filename, such as, for example, random. This technique has the added feature of concealing the actual name of the image file. If someone attempts to bookmark the image, or even if they right-click an image to save a local copy of it, they will not necessarily get the same image that they saw in the page.
This technique also allows proxy servers to cache the image, even though it is randomly served. The proxy server will not see the actual filename, but will only see random.
When using a more traditional random image mechanism, the proxy server would see each individual image filename instead and would cache each of those individually. Hash-Type Maps The previous two methods, particularly the first one, suffer from slowness. In the first example, we made a system where any Apache configuration directive would be rewritten to the documentation for that directive.
This works well if your map file contains a few dozen directives. This is because the rewrite file is plain text and unindexed. As the file grows, so does the average time taken to do a rewrite.
The solution to this problem is to use an indexed file, such as a DBM file. This allows for much larger lists of rewrite mappings without any loss of performance. Using a dbm: map type allows you to do this. If '-', use stdin. If not specified, will use the APR Default. It is important that you use the same DBM library as was used to build Apache, so that the format is understandable to Apache.
If you are running a version of Apache that does not have the httxt2dbm utility available any version before 2. The prg: rewrite map type lets you do exactly that. The example given here will be in Perl, because Perl is exceptionally good at handling text string manipulation, but you can write a rewrite program in any language at all.
The syntax for using this map type is identical to the other map types. The file path points to the location of the script or program you wish to execute to perform the rewrite. Doing this with just RewriteRules would be cumbersome.
The script to do this translation in Perl is as follows:! The program is started up when Apache starts up and is kept running for the lifetime of the Apache process. It is therefore important to keep our rewrite scripts as simple as possible.
A rewrite program that hangs or crashes may cause the containing Apache process to wait indefinitely for a response and thus hang that particular child process. While this is an exceedingly simple example, external programs can do things arbitrarily complicated, such as looking up responses in a database or sending email when certain URL patterns are seen. Internal Functions In addition to writing your own rewrite maps, there are several internal functions that you can call in order to assist in your rewriting.
These are available via the int: map type. There are, at the time of this writing, four internal functions you can use in this way, as shown in Table Internal RewriteMap Function Names Function Name Purpose Toupper Converts the argument to all uppercase characters Tolower Converts the argument to all lowercase characters Escape Converts any special characters in the argument to hex encoding Unescape Converts any hex-encoded characters back to the special characters they represent Internal functions may be associated with a map name in the usual way, using the RewriteMap directive.
Summary The RewriteMap directive is greatly underused and is appropriate for many situations in which people have rule sets of dozens of RewriteRule directives. Maps may be one of five types—txt, rnd, dbm, prg, and int—and they may be used in any RewriteRule directive to assist in rewriting URLs. Some of them were actually useful, while others existed purely to introduce concepts.
This chapter takes a practical turn, in that the examples offered actually solve real-world problems. As always, if we are in fact using this in an. Most well-written code will deal gracefully with blank arguments, and it makes a lot more sense to do this processing in the PHP or CGI, or whatever than to try to do it in the RewriteRule, where it is far less efficient. The question mark? As we proceed deeper into the URL structure of the website, each additional argument will be passed to the handling script.
What if we have more than nine arguments? Solution Use RewriteMap with a prg: map type. Such a RewriteMap program would need to loop over the entire contents of the string and process it sequentially. A simple example of such a RewriteMap follows.
Within a RewriteMap, we can do whatever transforms we like without regard to a limited number of arguments. Usually, this can be done with the Redirect directive, but in the case of a sitewide change, Redirect can become cumbersome. The old URLs should continue to work because people have bookmarked them. This will result in a round-trip back to the browser, and the user will see in their address bar if they notice the new URL and have an opportunity to bookmark the new address in preference to the old one.
Only the final file extension will be changed. Any query string information that had been passed to the original URL will also be retained, which is behavior that we would not get if we had used a simple Redirect or RedirectMatch directive. It seemed like a good idea at the time, but there are two different places that files could have ended up.
We want to look in both places when a file is requested. The -f test checks to see if the file is in the requested location. This process could be continued with another rewrite rule set in that other directory, too, if the problem was bigger than just two alternate locations. The long-term solution is to figure out which image references are pointing the wrong place and fix them. While this takes longer than simply doing a -f check, it is also far more robust, as a -f check will only look for files within the document directory.
Problem: We Require a Canonical Hostname Although there are several possible hostnames that can be used to reach our website, we want to require that everyone use one in particular. It is therefore very important to understand what this recipe is actually saying. In the RewriteCond, the dots are escaped because it is a regular expression. In the RewriteRule, they are not, because it is a literal target string.
The [NC] on the RewriteCond allows people to use an uppercase or mixed-case version of the hostname. If you wish to be even more restrictive than that, you can remove the [NC] and be just as controlling as you want.
This causes a problem if you have multiple name-based hosts on that same IP address. Discussion Because the rewrite happens after the SSL connection has already been negotiated, the user will probably still receive the browser warning about getting the wrong SSL certificate.
This will likely be a little confusing. Note that this rule set goes inside the SSL virtual host. Putting it elsewhere will likely cause it to be ignored. In the event that we have access to the main server configuration file, such a rewrite would be unnecessary, since we could simply put a Redirect directive in the non-SSL virtual host. However, when we are restricted to using.
Summary Although your particular rewrite needs are likely to be different from the ones shown in this chapter, the techniques listed here should be helpful in teaching you to craft your own rewrite expressions. Looping Although looping was discussed in Chapter 5, it is worth mentioning again here, as it is perhaps the most common example of the use of conditional rewrites. As one simple example of this, consider the situation where we have a website that is temporarily down for maintenance, and the administrator thinks it would be a good idea to redirect everything to a page explaining that the site is temporarily down: RewriteEngine On RewriteRule.
This is referred to as a looping rewrite rule, because the rewrite target matches the rewrite pattern. There are a few different ways to address this problem. The simplest of these is to impose a rewrite condition on the rewrite rule.
So, if you were to have this same rewrite block in an. Again, there are a few different ways to address the problem. Another method involves expressing the rule set as a file path.
As you can see from the preceding example, the rule set presented uses a [R] flag, indicating that the target is a URI to which we want to redirect. The default behavior of RewriteRule is to treat the target as a file path. The [L] flag Last ensures that the rule is run immediately, rather than having a chance to consider other rewrite rules that may be in effect in the same scope. And as before, things are slightly different when the rule appears in an. The purists among you1 have likely been grumbling throughout this example about the.
And probably my tech editor, too! Rest assured that I included it here so that I could make this remark. It would have been far more efficient, on two counts, to simply write the rule as follows: RewriteRule.
That is, it will match on the first character of the request and stop there. Thus, it will take considerably longer to run. Additionally, since we have enclosed. The moral of this story is that whenever you either use a repetition character or capture a result in parentheses for use as a backreference, you should consider whether this is really necessary or unneeded overhead. As a further example of this kind of waste, you will frequently see. However, the rest of the regular expression the.
The regular expression engine will run out to the very end of the string matching additional characters, which it is then going to ignore. Problem: We Want to Show a Competition Website Only During a Competition In Chapter 5, the example given was a time-based rewrite, where one page was provided during the day and a different one during the night.
This will require two conditionals: the date-based one and the test to see if the users have been here before. Next, we check to see if the user has already come in through the front door. We do this by checking for the presence of a cookie called frontdoor with a value of yes. The RewriteRule also sets a cookie, which will cause the third RewriteCond to fail the next time this user comes to the site.
RewriteCond conditions are additive by default. That is to say, they are implicitly AND conditions, and all three conditions must be satisfied for the following RewriteRule to be applied. It might be more useful, and less jarring to users, to rewrite that request to an informative page telling them that the contest is over and that they should try again next year.
There are a variety of reasons for wanting to do this. Certain techniques work in one browser and not in another, and so you may wish to deliver different content based on which browser is being used. Or perhaps you have an ideological reason for wishing to forbid entrance to people using a particular browser. In either case, the technique is the same. In this case, there are three versions of the page.
Order deny,allow Deny from all Allow from We want to have users log in, and then we want to serve different content based on the username that the user supplied. The advantage of this approach is that we can give out one URL to all of our users, and it will magically give them the right content based on their login information.
The RewriteCond there, while it may initially appear to be unnecessary, forces the initial authentication. The RewriteCond causes the rule to be skipped, and the authentication is performed. Once that happens, the rule gets run the second time through, and everything works smoothly. Many websites, for whatever reason, force all of their users to enter through the front page.
Personally, I think that this is annoying, and that deep linking is a tribute to the usefulness of your website. Forcing people through the front page merely makes it harder for users to get the information that they came for.
But this recipe provides the means, without endorsing the desire itself. On every request, the RewriteCond checks for the presence of a cookie indicating that the user has been through the front page. In the event that the cookie has not been set, the request is redirected to the front page of the site.
Once the user has been to the front page of the site, any other requests will not generate the redirect, since the cookie is already set. This will, of course, break any bookmarks or direct links for anyone who has not first visited the front page. The technique supplied here will work for a variety of different file types once you understand why it works.
In particular, you want to prevent PHP files from being uploaded, because these files might contain malicious code. Likewise, if someone attempts to rename an existing file to have a. Preventing the initial upload goes a long way toward completely blocking these types of attacks. Problem: The Client Certificate Validation Error Message Is Indecipherable To ordinary people, when they receive an error message telling them that their SSL client certificate failed validation, the message is cryptic and not very helpful.
If it is not set to SUCCESS, we know it failed, and we redirect requests to a detailed page telling the end user what happened and what they can do to fix it or who to contact for further details.
Ordinarily, we would handle the custom error message causing the ErrorDocument directive, but in this case, there is not a distinct error message associated with this error condition, so we have to look for some other indicator of the error. Summary Any environmental conditions can be used to decide whether or not to run a RewriteRule. This allows you to be very creative in your rewriting and to make URLs magically do the right thing under different conditions. Access control is the term given to any technique used to determine who is allowed into your website and who is kept out.
This can be based on any criteria, from the IP address of the browser, to the time of the day, or any other criteria that occurs to you. Address-Based Access Control If you are performing simple address-based access control, doing so using the allow and deny directives is the easiest and most efficient approach: Order allow,deny Allow from all Deny from If you are using an.
That is, the file would contain only these lines: Order allow,deny Allow from all Deny from For example, if you wished to deny access to URIs starting with a or b, you could accomplish this with the following configuration: order allow,deny Allow from all Deny from That is, any time you have the following: ConfigurationLinesHere that functionality will be duplicated by placing an.
The reverse is also true: anything you can put in an. At the very least, this gives you a way to compare and see if my claims are accurate. Clients whose address starts with Using a regular expression of just Second, and most important, I want to draw your attention to the RewriteRule.
The regular expression to which we are comparing the request is. By using the? The less we have to match, the more efficient the expression will be. As you experiment with regular expressions, and encounter regular expressions that other people have written, you will frequently encounter rewrite rules that use.
The regular expression. Of course, it will match. This means that for a string of n characters, n comparisons must be made. If you use the pattern.
This causes a significant performance improvement. Since only a single comparison is made, you will have the same execution time regardless of the length of the requested URI, whereas a comparison string of.
The general rule to remember is that you want to find the simplest possible regular expression that will match the desired string, not the most complete one. Never use. Problem: We Want to Deny Access to Several Directories at Once Restricting access to a large number of directories can be tedious if you have to manually restrict each one.
You should use or a and a Deny directive, as discussed earlier. However, this rule set does illustrate how to do access control based on an arbitrary URL pattern. Since , , , and cannot be used in. This guarantees that it is a directory name, rather than a file, that happens to start with one of those letters. And, finally, I have one more remark about possible alternate approaches.
Rather than using the [abAB] character class, you could instead use [ab] and then append a [NC] flag on the end of the RewriteCond to make the condition case insensitive.
We have a particular robot or bot, or spider that is hammering our website, and we want to block its access to our site. There are a number of ways to approach this. What could be easier? In this particular case, the RewriteRule approach turned out to be slightly slower, in my tests. The benchmarks that I did had the RewriteRule trailing by 10 percent. The advantage of the RewriteRule, in this case, might be a greater flexibility or the ability to combine these criteria with other rules also being run.
However, if the only consideration is the User-Agent type, then it is more efficient to use the SetEnvIf approach. Indeed, most malicious bots will report themselves as a common browser type, so that they appear innocuous in your log files. But this can also be done with plug-ins for most commonly used browsers.
This problem tends to arise most frequently when someone sees an image on your website, likes it, and embeds it directly in one of their web pages.
This means that every time someone loads this page from their site, it generates requests to your site. They are, in a sense, stealing your bandwidth to serve their website. What would be preferred would be if they saved a local copy of that image and then served that copy from their site. Or, of course, if they used their own images, rather than stealing your hard work for their site. Or, more accurately, it checks for requests that did not originate from our request, so that it will only run the RewriteRule in that case.
This can happen for a variety of reasons. Some browsers, for example, can be configured never to return referer information, for reasons of privacy. And a browser will not return a referer if someone gets to the page via a bookmark or by typing the URL directly into the browser address bar. The target of the rule is -, which indicates that no rewriting is to be done. But the flag, [F], indicates that a Forbidden status code is to be sent to the client.
However, the most common result when you do this type of redirection is that the site that is using your image will immediately notice the change and stop attempting to use the remote image at all. One notable exception to this is time-based restrictions, as discussed in Chapter 5. Apache has provided this functionality since version 1. There are two types of virtual hosts: IP-based virtual hosts, where each virtual host requires its own IP address, and name-based virtual hosts, where multiple virtual hosts can coexist on the same IP address by virtue of having different hostnames.
In this chapter, we will concern ourselves exclusively with name-based virtual hosts. Creating a virtual host is a simple matter. However, when you need to create hundreds or thousands of virtual hosts, it becomes necessary to find a simpler way of managing them, since having hundreds of virtual host configuration blocks in your Apache configuration file becomes unmanageable.
A number of techniques are available for dealing with this problem. The websites will be distinguished by their names. Also, each host has an alternate name, or ServerAlias, without the www part of the hostname. Creating virtual hosts does not cause the hostname to resolve to your IP address. You will also need to create DNS host entries so that the name resolves to your IP address, but this topic is beyond the scope of this book.
Unfortunately, once you have a few hundred of these virtual host configuration blocks, two problems start to appear. For example, what I typically do is put each virtual host configuration in its own file named, for example, rcbowen. Using per-vhost configuration files is good enough for most web servers. However, there are times when you want dynamically generated virtual host configurations. There are a variety of different reasons this might be needed. Perhaps you have a lot of customers.
Or perhaps you are lazy. But most of the time, these motives can all be put under the same general heading. I want my web server to just do the right thing and not make me tell it every time. It is also worth noting that when the number of virtual hosts becomes large, the configuration consumes a large amount of memory, and server startup time is proportional to the number of virtual hosts you have. First, we need to decide on a common directory structure into which all of our virtual hosts will be placed.
For example, we might decide that the content for a virtual host named www. To accomplish this, we need to think of the hostname for the virtual host in three parts. Thus, www. Fortunately, there is a very simple solution to this: just look at the hostname backward. This time, instead of looking at www.
Well, some people find the other explanation is somewhat easier to understand, so it makes sense to start there. But when you can count from the right or the left, it allows you to handle hostnames whichever way makes the most sense to you.
An alternative approach is to create symbolic links for all the various possible aliases for a given virtual host. You want to subdivide a little further. You may want to separate the subdirectories into one directory per letter. Or, for the really huge ISPs, perhaps you want to subdivide even further. So, if you want to divide into one directory per letter, you can consider the first letter of the second part.
That is, if you want to put www. The variations on this are, of course, without end, depending on the number of virtual hosts you have and the amount of complexity you can put up with.
Incorrectly, in my opinion. You need to pick one approach or the other. It will very likely break things. All of the virtual hosts log to a single log file. It does not permit per-vhost changes. The most common solution to this is to allow the various virtual hosts to modify their configuration using. You can also modify their configuration using blocks in the main configuration file, but, since the goal was to avoid having to change the configuration file at all, this is usually undesirable.
The RewriteMap is necessary because the hostname might be uppercase or lowercase, and we need to make sure that we have only one possible target file path for each request. Using the internal rewrite map function tolower, we lowercase the requested hostname and rewrite to a file path created using that hostname. This approach, as shown here, immediately creates a couple of problems. We want those two hostnames to be treated the same, and this requires a little more work.
The leading www. Now, requests for both www. These various parts are then available to be used in the rewrite rule, and we end up with a request for www. Although it is extremely unlikely that you will be rewriting virtual hosts in an. In order to make those Alias directives continue to work, we need to make sure that the RewriteRule ignores them when it comes to rewriting the URIs to file paths. Fortunately, there is at least one fairly simple solution to this problem.
Requests for CGI programs are mapped into the directory via a two-step process. Thus, each dynamically created virtual host now has its own CGI directory. Virtual Hosts with RewriteMap There remains one alternate approach we might take to create dynamic virtual hosts that is well worth discussing. That is, any hostname that resolves to your IP address will be mapped to some directory. In either of these cases, RewriteMap might provide a better solution.
The first step is to create a map file, listing all of our approved hostnames and the directory path to which they should map. This file will look like this: www.
So the hostname example2. Assuming that we named the map file vhosts. Other than that, the virtual hosts can be located anywhere at all in the file system for this technique to work. When we move to mass virtual hosting, rather than having a separate block for each virtual host, it becomes more difficult to have individual log files for each vhost. There are a few different ways to solve this problem.
Which one is the best solution for you is, of course, up to you. But here are some suggestions. The disadvantage of this approach is that live log files contain entries from all of the virtual hosts and are therefore less useful than they could be.
Two things are necessary for this approach. In this way, every line in the log file is clearly associated with the virtual host to which it is attached. This also allows us to split the log file out into its component parts later on.
In the case of dynamically generated virtual hosts, that would cause all log entries to have the same hostname— that is, whatever was set in the main ServerName directive. The second step is to split up the file into its component parts. This is done with the split-logfile script, which comes with Apache. Unfortunately, if you have installed Apache from a third-party package, this file might not have been installed at all. You will need to look around.
The script is used by running it with the log file as input, and it creates one file per virtual host in the directory where you are running the script. Usually, you will run the split-logfile script periodically, perhaps via a cron job. This problem can be at least partially solved by using a piped log file handler, but there is one very large caveat. When you are doing dynamic virtual hosts, having just a single log file ensures that you will not use up a huge number of file descriptors.
If you use piped log file handlers to create a single log file for each virtual host, you will start to use up large numbers of file descriptors and run the risk of using up all available file descriptors, thus causing your server to die. Having said that, it is possible to use a slightly modified version of the split-logfile script to have a piped log file handler with a single log file for each virtual host.
Since split-logfile expects input on STDIN, it seems like it should be ideal for use as a piped log file handler. Unfortunately, it creates the log files in the directory in which it is run, whereas when you are using a piped log file handler you want to make sure that you can control exactly where it puts the output. Summary With one or more of the techniques described in this chapter, you are able to create dynamic virtual hosts for your web server.
It may indeed work the way you expect, but then again, it might not. For best results, you should pick one technique and stick with it. This will lead to scenarios that are easier to troubleshoot and fix when things go wrong. This technique is used for a wide variety of purposes, such as load balancing and server migration. Apache comes with several modules that allow you to run a proxy server.
With Apache 1. And in 2. In Apache 2. That is to say, the browser user is not aware that the change has occurred. The reasons for it being on another server are varied, of course. Forward proxying describes a situation where browsers on your LAN have this server configured as their proxy server for all outbound web requests.
This is how proxying was initially used most commonly. The reasons for forward proxying are primarily performance and control. If all outbound requests are funneled through a proxy server, this gives an easy way for someone to control what websites users are going to, via some kind of filtering mechanism placed on that proxy server.
And if the proxy server is also able to cache requested content, this increases the perceived speed of web traffic, since commonly requested documents can be retrieved from the cache, rather than having to connect to the actual website to retrieve the document.
That is, an inbound connection, from the outside internet to your web server, is proxied to one or more back-end servers.
The risk occurs when a proxy server is configured to be an open forward proxy. This term means that anyone can proxy anything they like through the proxy server. Thus, users can use an open proxy server to circumvent corporate content filtering restrictions, such as visiting pornographic websites via your proxy server, thereby hiding this activity from their network administrators. Or, web-based attacks can be launched at a website through your proxy server, so that those attacks appear to come from your network, rather than from that of the real attacker.
So, before we go any further in this chapter, I want to point you to some basic security tips for setting up a secure proxy server. Fortunately, for most scenarios, the solution is very simple. Forbid forward proxying, and the problem goes away. This is the best possible scenario. If, on the other hand, you are actually setting up a forward proxy server and happen also to be using it for reverse proxying, another solution is necessary.
The syntax for this will differ slightly depending on whether you are running Apache 1. Apache 1. You will, of course, have to replace Proxy requests made explicitly via a ProxyPass directive or with a RewriteRule with a [P] flag will be able to get through, because the request will be seen as coming from Apache 2. Proxy requests are permitted from the local network and from the machine itself. This protects you from unknown clients proxying content through your server.
The ProxyPassReverse directive ensures that any response headers containing the images. This is very important because without it you could run into a situation where a browser is receiving redirect headers for a machine that is not in fact reachable at all. Once you start doing this kind of global proxying, the most common question to come up is how you can exclude certain things from this proxying.
As before, the images directory will be moved to another server. Unfortunately, images are scattered throughout the entire server directory structure, rather than all being conveniently located in one place.
RewriteEngine On RewriteRule. Any request for a file ending in jpg, gif, or png will be proxied to the back-end image server, and, since the directory trees match, the image will be there. As more image files are added to the server, a more logical structure for image placement may be followed, eventually removing the need for this much complexity.
The static content can be served very quickly, while the dynamic requests are proxied to a back-end server that runs only that content. A fairly common configuration for this is to run that secondary server on the same physical machine, but on another port. Using this technique, along with a proxy, you can fetch remote content and modify it slightly before passing it on to the end user. Adapting this to translate into Swahili or ancient Greek is left as an exercise for the reader.
There are a variety of other filters also available in this package. While this is good for a laugh, there are rather serious problems involved in using this for a real site. Excluding Content from the Proxy I was recently in a position of migrating a website to Apache from another web server software.
At the same time, design changes were being made, and much of the code was being moved to PHP from another language. It was decided that the best way to proceed was to put Apache on a new server and proxy all requests through to the old server. Then, as content was moved, or new parts of the website were put on the new server, those portions of the website would no longer be proxied. This character had a rather distinctive accent and dialect.
This let us transparently migrate content to the new server and still keep all the existing content working until such time as we could get around to fixing it. So far so good. However, the list of exclusions grew with every week, and this very quickly got out of hand. Looking Somewhere Else The next solution that we came up with was much simpler. In words, it goes something like this.
If the content is on the server, then serve it. This will also probably require some exclusions, but it should be more flexible and require fewer changes to the server configuration. RewriteEngine On Is the requested resource here? The rewrite log can also be good for optimizing these rules, by figuring out how they are actually being evaluated.
Many of the techniques discussed in this chapter assume that you are the administrator on your own server, or that you at least have a shell account and access to basic command-line tools. If this is not the case, then it will be in your best interest to install Apache on your desktop system and do this troubleshooting locally before moving content and rewrite rule sets up to your server.
Of course, experimentation on a test server, rather than on the production server, is a good idea in any case. RewriteLog Your most important tool in debugging your rewrite rules is the RewriteLog directive. RewriteLogLevel should be set to a value between 1 and 9. The least verbose of these values is 1, and 9 is the most verbose. For the purposes of troubleshooting, you should have this value set to a higher rather than a lower number.
However, be aware that this produces enormous quantities of log messages very quickly and should not be enabled on a production server. The first four fields are the same as the first fields in the access log. Next, we have a field that is almost always blank, the remote ident of the client. The third field is the username of the remote user, if they had to authenticate to fetch this resource.
And fourth is the current time and date, including the time zone offset. The two possibly useful pieces of information in there are the first and last strings. The first string indicates the virtual host to which the request was made. The initial indicates that the request was an initial request, as opposed to a subrequest. The part of the log entry that you really should be looking at starts with the number in parentheses. The initial number indicates the level of the log message.
However, the log messages that you will see will usually be between 1 and 5. Following the log level is the message itself. For the most part, these are very clear and self-explanatory. Note that the leading slash is part of the URI. If this rule set had appeared in an. The resulting image, if found, will be displayed in the address bar of your browser. And you can reduce the number of gratuitous error messages that appear in your error log by creating such a file.
You can obtain more information about favicon. Loop Avoidance In the second example, a slightly more complex rewrite is used, introducing a RewriteCond. It is worthwhile to compare these log entries to what happens in two other cases.
RewriteRule in. As we discussed very early in the book, when in a per-dir context, everything is assumed to be relative to that directory. For this example, consider the following. Consequently, what we have at this point is a file path, and not a URI at all. Thus, the RewriteRule pattern needs to be applied to a file path, instead of the URI that was originally requested.
The entry from the rewrite log reflects this fact. Since it matches, we move on to the next step. Regex Building Tools As the regular expressions you are working with become gradually more complex, it becomes useful to have a tool that can help you test these expressions and see what they actually mean. Since it is in Perl, it can be used on any platform where Perl is available. A few online tools are also available, which, although they tend to be less full-featured, will usually do the job.
For those more attuned to the command line, there is also the pcretest utility, which comes with the pcre library. It allows you to compare a regular expression against a test pattern, telling you what matched and the values of any backreferences, if any.
Summary The RewriteLog is going to be your most useful tool when attempting to troubleshoot your rewrite rule sets. Once you have your rules working correctly on the test server, you can move them to the production server and be assured that they will work correctly there.
It contains many of the recipes in this book, as well as those in the Rewrite Guide in the online documentation. This is understandable, given the complexity and power of the module.
But there is an effort under way, at the time of this writing, to refurbish the documentation and make it friendlier to the beginner. At the command line on any machine with Perl installed, type perldoc perlre for the Perl regular expression documentation. See regular expressions pcretest utility, for comparing a regular expression against a test pattern, per-dir per-directory context examples, 34—35 in RewriteRule directive, 32 when not to use, 34 per-dir examples, correlation between the URI and what RewriteRule has to work with, 34 per-directory per-dir context.
See per-dir perdirectory context period. Redirect, 6 Redirects, using RedirectMatch directive for more complicated, 5—6 regex building tools, for testing regular expressions, — Regex Coach available for Windows and Linux, 20 website address for obtaining, regex examples, 14—18 regex syntax, reference for, 7—14 regex tools, 18—20 Regular Expression Debugger Rebug , downloading, 19, regular expression examples, 14—18 Regular Expression Recipes: A Problem-Solution Approach, by Nathan A. Home The Definitive Guide to Apache mod rewrite [1 ed.
The Definitive Guide to Apache mod rewrite [1 ed. The Definitive Guide [Third Edition] , Apache is far and away the most widely used web server platform in the world. This versatile server runs more than half 24 KB Read more. Apache: The Definitive Guide [2 ed. However this book is a "five star" b 1MB Read more.
However this book is a "five star" b 91 1MB Read more. Apache: The Definitive Guide [3 ed. Apache: The Definitive Guide [Second Edition] , Apache is far and away the most widely used web server platform in the world. David Hows from 10gen, along with experienced MongoDB authors Peter Membrey and Eelco Plugge, provide their expertise and experience in teaching you everything you need to know to become a MongoDB pro.
Jython is an open source implementation of the high-level, dynamic, object-oriented scripting language Python seamlessly integrated with the Java platform. Jython is freely available for both commercial and noncommercial use and is distributed with source code.
Jython is complementary to Java. This book begins with a brief introduction to the language and then journeys through Jythons different features and uses.
The Definitive Guide to Jython is organized for beginners as well as advanced users of the language. The book provides a general o Get the definitive guide on all the fundamentals of Terracotta as well as user secrets, recipes, and prepackaged frameworks.
Written by Terracotta's chief technology officer Ari Zilka and his team, The Definitive Guide to Terracotta: Cluster the JVM for Spring, Hibernate and POJO Scalability covers the following: High Availability HA nth degree scaling and clustering for traditional J2EE and Java EE 5 applications using Seam or other application as well as Springbased enterprise applications Everyday Terracotta using its prepackaged frameworks and integration recipes, including configuration and customization for your application tuning, no matter the scale Power user secrets available, including config modules, customized advanced performance
0コメント