SEO Optimization for URL rewriting by apache/tomcat JSP/Key Points of second-level domain names

Apache has been used for a long time, but it has only been used for a long time. So there is a taste of makeup in these four or five days: Since the company cannot provide a good system administrator, it can only be self-serving. After combining Apache and tomcat for SEO optimization, four or five days later, I had a unified understanding of the basic logic framework of these tools.
The knowledge of URL rewriting should be aimed at the following needs: SEO engine optimization in favor of HTML, and non-quantitative second-level domain names are provided to facilitate module management and promotion. Although the search engine cannot recognize that dynamic pages are technically impossible, I think the biggest possibility is that for static hardlink, if there is no search engine, it will get a 404 identifier. For dynamic pages, the response is not always correct. In this way, it is not easy for search engines to maintain and classify indexes.
After an in-depth understanding of Apache mod_rewrite, it is found that several key guidance is often lacking in its documentation and introduction articles, and specific details are involved too quickly. To understand the work of mod_rewrite, we must first understand that mod_rewite works on directories. In other words, the RewriteRule of each directory is independent. The rewriting of each directory is both the highest-level container and the lowest-layer container. Therefore, the RewriteRule definition is the location of each directory, <Directory $ dir/> or the Directory. htaccess.
Second, mod_rewrite is a set of flat-Level Rules that lack logical functions. Therefore, each rule in each directory setting is repeatedly converted. [L] indicates that the matching is completed only once, it also needs to re-match and output the request without any matching entries. In this way, if there are more rules, not only will the performance go down, but it is easy to get confused, therefore, use mod_rewrite with caution and use mod_rewrite to match second-level domain names. In this regard, the mod_rewrite designer expects to use regular expression matching, or allows users to call perlShell as an application in the complex matching logic. But this makes development complicated.
Because mod_rewrite is directory-based, its priority is lower than that set by virtual hosts, while that of VirtualHost is lower than that set by VirtualDocumentRoot. Because the ServerName of VirtualHost cannot use regular expressions for IP header-based matching, there are huge restrictions on using VirtualDocumentRoot to set multi-level domain names. Therefore, a slightly diversified application will face insurmountable conflicts. Therefore, simply using a virtual host or URL rewriting is not efficient. At this time, the main path should be html guidance, which can meet the requirements of SEO like hardlink, it does not affect users' browsing. The most important thing is that the main solution can be centralized into an application, which simplifies the project technology and reduces the project cost.
Basically, the use of php for mod_rewrite and second-level domain names is based on the following reasons: Session Consistency Maintenance. There is a lot of complexity when mod_rewrite is applied to the jsp site. Because mod_rewrite is targeted at directories, it will inevitably interfere with the operation of directories; while the context of jsp is determined by the Basic directory as the application; in this way, when the directory is clear, jsp can normally recognize the maintained session under different domain names and virtual hosts, but once the directory is incomplete, like using a second-level domain name, whether this directory is interpreted as a URL rewrite or virtual host setting, the browser regards it as two Session requests, resulting in confusion. Therefore, to use a second-level domain name on a jsp site, there is no way to use a hard html connection guide. Of course, the Redirect method can solve the problem on the surface, but in this case, the meaning of SEO is lost; and URL rewriting is originally for SEO; so why rewrite?