Apache has been used for a long time, but it is only used for a long time, and it is necessary to say that it is not possible to talk. So the four or five days of the taste of the courses are inside: Since the company can not provide a good system administrator, it can only be self-satisfied. After four or five days after the combination of Apache and Tomcat, there has been a unified understanding of the basic logic framework of these tools.
The understanding of the URL rewriting needs to be designed for this: the SEO search engine optimization of HTML, as well as providing unpivalent secondary domain name facilitates module management and promotion. Search Engine does not know how dynamically pages are technically unlike; I think the biggest possible is for static hardlink, if there is no search engine gets a 404 ID; and for dynamic pages, the reaction is not necessarily. This is not convenient for search engine maintenance and distribution.
After an in-depth understanding of Apache MOD_REWRITE, it is found that there are several critical guides in its documentation and introduction articles; it is too fast to involve specific details. To understand the work of MOD_REWRITE, you should first understand that mod_rewite is working for directories. In other words, the REWRITERULE of each directory is independent. The rewritten of each directory is both the highest layer of container. Therefore, the REWRITERULE definition is where the location is located in the location of each directory,
Second, mod_rewrite is a set of planar rule sets that lack logical functions, so each rule setting is repeatedly converted in each rule, [L] is only indicative of one match, it also needs to reappear, without any entries The request will only be output after matching, so that if the rule is slightly more performance, it will drop straight, but it is easy to fall into chaos, so mod_rewrite should be used with caution, using MOD_REWRITE to match the secondary domain name. Be careful. In this regard, the MOD_REWRITE designer is desirable to use regular expressions, or allow users to call Perlshell as complex match logical applications. But this will make development complicated.
Since MOD_REWRITE is based on the directory level, its priority is lower than the virtual host settings; and the VirtualHost host has a priority of the VirtualDocumentRoot. Since VirtualHost's ServerName is unable to use regular expressions based on IP headers, there is a very large limit for setting up multi-level domain names using VirtualDocumentRoot, and the application is slightly diversified. It will face conflicts that are difficult to overcome. Therefore, it is not very efficient to use the virtual host or the URL rewrite. At this time, the main path should be guided using HTML, which can meet the requirements of SEO like Hardlink, and will not affect the user's browsing. The most important thing is that the main solution can be concentrated to an application, simplifying project technology, and reduces the cost of the project.
Site using MOD_REWRITE and secondary domain names basically use PHP is approximately based on this reason: conformity maintenance of sessions. There is a lot of complexity when mod_rewrite is applied to the JSP site. Since MOD_REWRITE is performed for the directory, it must interfere with the operation of the directory; and JSP's context is based on the basic directory as the application's judgment; this, JSP is clear under different domain names and virtual hosts in different directories. It can normally recognize the maintained session, but once the directory is incomplete, it is like using the secondary domain name, regardless of this directory interpretation is from the URL rewriting or the virtual host setting, the browser will regard it as two session requests, Thereby cause confusion. Therefore, use a secondary domain name in the JSP site, in addition to using a hard HTML connection guide, there is no way. Of course, using the redirect method to solve the problem, on the surface, but this is lost SEO; and the URL rewriting is for SEO; then why should you write it? Moreover, this domain name / path and session relationship, different browser performance is still different. IE is only associated with the context path, while Firefox / Mozila / Netscape is also related to the domain name (secondary domain name). In this way, if you don't want to cause confusion, it is best to set the boundaries of rewritten. If you stop, you will only turn your rewrite as an entry, while others, with a complete main domain as the main domain name. It also means that relative paths are unreliable for images or static dynamic files. Regarding the loss of session due to path changes, whether it is a browser, it will automatically remove the session, resulting in a loss of sessions.
In summary, the URL secondary domain name in /.htaccess is rewritten, it is best to write a redirection to standard host and path from the beginning, so that many troubles have been saved, at the same time, for SEO, It does not affect the name of the name itself.
Intercept the string in the REWRITECOND condition as the rewrite variable: shutritecond% {http_host} ^ ([A-ZA-Z0-9 / -] ) /. Bbs / .home / .javanet / .edu $ [nc] REWRITERULE ^ $ http://home.javanet.edu/_AppHome/bbs/%1.html [l] Note () and% x, the former is the content intercepted in regular expressions, the latter is sequentially extractive;
Intercept the string of the URL in ReWriterUld as a rewrite variable: shutriterule ^ ([A-ZA-Z / -] ) /. Html /apphome/$1.jsp [], pay attention to it () and $, Is different from the REWRITECOND.
Also note that [l], although the last one in the chain is different, the filter forwarding rule chain is different from the firewall, this L is the end of this loop, not the entire rewriting process ends. The logic of rewritten is: while (there is no match) loop;
And the firewall rule chain is if-else-else ...;
In particular, I have developed a firewall like I have, I have to pay special attention to this rule, otherwise it is easy to fall into the dead cycle.
