Main

它它它它 Archives

March 26, 2006

W-8BEN 详解

简介

一般而言,非美国公民或居民所收取的美国来源收入,均须缴纳美国税款。作为在美国的证券经纪商,嘉信理财必须为非美国人客户预扣美国来源收入的美国所得(入息)税。

为了符合美国国税局 ("IRS") 的报税规定,非美国人必须向国税局及嘉信理财递交国税局表格 W-8BEN,申报所居国家以证实其为非美国公民或居民的身份。嘉信将根据客户在国税局表格 W-8BEN 上所申报的居住国家,预扣非美国人客户的美国税款。

如果帐户没有存备每名与帐户有关人士的有效国税局表格 W-8BEN 及附以所需的证明文件,嘉信便必须预扣帐户内 30% 的全部出售所得以及因公司重组所产生的其它现金收入。在没有有效国税局表格 W-8BEN 的情况下,嘉信亦必须预扣非美国人客户帐户内最高税率 (30%) 的税款,该税率高对一般居住在与美国有税务协议国家的居民的税率。嘉信将每年以国税局表格 1042-S,向国税局及帐户报告 W-8BEN 表格上涵括的资料。

请参阅国税局 Publication 515,以取得更多关于适用于非美国居民税率的资料。

确定非美国人身份

非美国人(或非美国居民外籍人士 "non-resident alien")是指不属于美国公民或美国合法居民的人士。外国人包括非居民外籍个别人士 ("non-resident alien individual")、外国公司、外国合伙人、外国信托、外国遗产、以及其它不属于美国人的人士。

如帐户内有任何持有人为美国公民或合法美国居民,该帐户可能不会被列为非美国居民帐户,而必须开设为美国居民帐户,并会将该名美国人客户的姓名列为首位帐户持有人。须申报的帐户活动会使用该名美国人帐户持有人的纳税编号报税,而该名美国人帐户持有人必须在国税局表格 W-9 上,证实其纳税编号。

客户必须自行确定他们是否美国居民。嘉信不能为客户确定其所居地。不过,如果嘉信得悉帐户持有人是美国人,直至收到该名帐户持有人的国税局表格 W-9 前,所有适当的帐户活动将会按照适用于尚未证实为美国帐户的预扣税率计算。

什么是美国来源收入?

概括而言,在美国税务规定下的“美国来源收入”释义为来自由美国公司或美国注册共同基金发出的证券的股息及利息收入。此外,来自美国国库债券及美国联邦机构债券的所得利息亦为美国来源收入。因此,在某程度上,如您有来自美国公司、美国注册共同基金、美国国库债券或美国联邦机构债券的股息或利息,其数额将包括在我们必须送交国税局的每年报税表内。

什么是非美国居民外籍人士预扣税 (Non-Resident Alien Withholding or NRA Withholding)?

一般而言,一名外国人必须为其美国来源收入缴纳美国税款。必须缴税的投资收入包括美国公司分派的股息收入,以及某些利息收入。非美国人的税率是 30%,不过,视乎该名外国人的国家与美国之间的税务协议,税率可能低于 30% 或者获豁免税款。国税局规定嘉信须从付给外国人的收入中预扣本项税款(“非美国居民外籍人士预扣税”NRA Withholding)。

在美国的证券经纪商必须每年以国税局表格 1042-S,向国税局申报所有该公司每个帐户的美国来源收入。所有给外国人的收入(包括非美国居民外籍人士、外国机构及政府),亦可能受到非美国居民外籍人士预扣税的规定。

您应咨询您的税务顾问,以确定您帐户内任何所得收入的预扣税款,是否符合视乎您所居地而定的外国税款减免资格。

国税局表格 W-8BEN 与非美国居民外籍人士预扣税 (NRA Withholding)

为了预扣正确的税款(税率一般由 0% 至 30% 不等,视乎帐户持有人的所居国家),非美国人客户必须向嘉信提供有效的国税局表格 W-8BEN,并附以国税局或嘉信规定的所需证明文件。

在向嘉信递交国税局表格 W-8BEN 后、或在原来的国税局表格 W-8BEN 上更改资料后的第三年的 12 月 31 日之前,客户必须重新证明其非美国人所居地身份。如果我们没有每名帐户持有人的有效国税局表格 W-8BEN 纪录,我们必须以最高税率(现时为 30%)预扣帐户内股息及利息的税款。此外,我们亦必须预扣帐户的出售所得及其它收入的 30% 税款。

请用英文填写

W-8表格PDF版下载W-8表格PDF版下载
Part I

1.帐户名称 (Name of individual or organization that is the beneficial owner)
-> 请填写您的姓名或第一帐户的帐户名称

2. 国籍 (Country of incorporation or organization)
-> 请填写您的国籍

3. 帐户种类 (Type of beneficial owner)
-> 个人帐户请选 Individual -> 共同帐户必须填写两份 W-8 BEN, 帐户持有人及共同子持有人都必须填写 -> 监护人帐户, 被监护人必须有美国社会安全号码, 不需填写W-8BEN

4. 永久居住地址 Permanent residence address
-> 外国帐户需有填写非美国住址

5. 邮寄地址 Mailing address
-> 如果不同与您的居住地址

6. 美国赋税编号 (没有者不需填写) U.S.Taxpayer identification number. -> 如果您有美国税务编号请填写

7. 外国赋税编号 (选择性提供) Foreign tax identifying number

8. 第一理财帐户号码 Reference number(s)

Part II 如果您的国家与美国有关税优惠, 请圈选 a 并填写国籍. 中国大陆, 新加坡必须填写 Part II 台湾, 香港特区不须填写 Part II

Part III (选择性提供)

Part IV 签名 Sign Here

表格用途:
本表格适用于非美国居民向美国国税局申报美国所得税减免时使用。如果您所居住的国家为美国的税务减免互惠国,
您便可能符合减税或免税的资格。请到美国国税局网站 www.irs.gov 做进一步了解。请将您的 W8 表格寄到史考特证
券,不要送到美国国税局。
表格不适用于: 应使用表格
? 非美国居民本年度在美国居住超过 183 天(含 183 天),但持有 F,J,M,Q 签证者不在此限。如您持有上述
种类签证,请在此注明签证类别:
? 美国公民,永久居民或美国税法所定义的外国居民………………………………………………………………W9
? 申报税务减免的个人与美国有经贸往来………………………………………………………………………W-8ECI
详细资料请查阅美国国税局 W-8BEN 英文版全文说明。
表格填写简单说明:
第一部分:所得个人资料
第1 点:姓名。
第2 点:国籍。
第3 点:所得单位种类:个人请勾选 Individual; 若为共同账户请分别填写 W-8BEN。
第4 点:永久居住地址(请勿使用邮政信箱 PO Box 或转寄地址,还有国家名称请勿简写。)
第5 点:邮寄地址(如果不同于永久地址请另填写,国家名称请勿简写)。
第6 点:美国税号 SSN,ITIN 或 EIN 号码(如果您需要填写)。
第7 点:外国税号(如果有)。
第8 点:扣缴单位使用的参照号码。
第二部分:税务减免申报(若适用)
第9 点:确认以下勾选的均使用
? 勾选 a 项:如果所得期间所得申报人居住在 (国家名称),其为美国的税务减免互惠国。
第三部分:申明
本人申明以上所填资料属实而且完整。
? 本人(或授权人)为本表格所提及的所有所得申报人。
? 所得个人不是美国税法规定的美国申报人(US Person)。
? 本人的所得不属美国的贸易或商业行为。
? 本人确实符合美国的税务减免互惠的资格。
除此之外,在此申明,预扣税款单位有权预扣我的税款。
签名栏(SIGN HERE):所得个人或授权人签名/日期/(月日年)/授权代理。
注意:
? 在交出 W-8BEN 表格后您的身份若有变更(变成美国公民或居民),请于 30 天内主动通知预扣税款单位。
? W-8BEN 表格的有效期为签署年起至第三年年底止。
? W-8BEN 的中文简要说明仅为方便华人客户提供。本公司客户须以美国国税局所提供之英文原本为准。您可
到史考特证券表格中心下载 W-8BEN 英文版全文说明或到美国国税局网站 www.irs.gov 做进一步暸解

March 20, 2006

What would be a good SEO strategy?

What would be a good SEO strategy?

Before you launch your site, you should have done the following:
- Optimized your <title> tags on each page to contain 1 - 3 keywords
- Create unique Meta Tags for each page
- Used appropriate markup where necessary (<h1>, <em>, etc.)
- Used keywords liberally yet appropriately throughout each page
- Designed the navigational structure of the site to channel PR to main pages (especially the homepage)
- Used Search Engine Friendly URLs (if necessary)
- Created a complete website with plenty of quality content
- Used keywords in your domain and url (http://www.keyword1.com/keyword2/keyword3.html)

Immediately after launching your site you should do the following:
- Submit your site, by hand, to all major search engines
- Submit your site to all free directories (dmoz, yahoo (if applicable), etc..)
- Begin a link building campaign (attempting to get keywords in the reciprocal link anchor text)

Finally, as part of an ongoing strategy:
- Continually update your website will quality content
- Continually seek free and reciprocal links preferably from sites in your genre

* Remember, build your website for human beings; not the search engines!

Hypertext Style: Cool URIs don't change.

From:http://www.w3.org/Provider/Style/URI
--------------------------------------------------------------------------------
Cool URIs don't change
What makes a cool URI?
A cool URI is one which does not change.
What sorts of URI change?
URIs don't change: people change them.
There are no reasons at all in theory for people to change URIs (or stop maintaining documents), but millions of reasons in practice.

In theory, the domain name space owner owns the domain name space and therefore all URIs in it. Except insolvency, nothing prevents the domain name owner from keeping the name. And in theory the URI space under your domain name is totally under your control, so you can make it as stable as you like. Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running. Then why are there so many dangling links in the world? Part of it is just lack of forethought. Here are some reasons you hear out there:

We just reorganized our website to make it better.
Do you really feel that the old URIs cannot be kept running? If so, you chose them very badly. Think of your new ones so that you will be able to keep then running after the next redesign.

We have so much material that we can't keep track of what is out of date and what is confidential and what is valid and so we thought we'd better just turn the whole lot off.
That I can sympathize with - the W3C went through a period like that, when we had to carefully sift archival material for confidentiality before making the archives public. The solution is forethought - make sure you capture with every document its acceptable distribution, its creation date and ideally its expiry date. Keep this metadata.

Well, we found we had to move the files...
This is one of the lamest excuses. A lot of people don't know that servers such as Apache give you a lot of control over a flexible relationship between the URI of an object and where a file which represents it actually is in a file system. Think of the URI space as an abstract space, perfectly organized. Then, make a mapping onto whatever reality you actually use to implement it. Then, tell your server. You can even write bits of your server to make it just right.

John doesn't maintain that file any more, Jane does.

Whatever was that URI doing with John's name in it? It was in his directory? I see.

We used to use a cgi script for this and now we use a binary program.
There is a crazy notion that pages produced by scripts have to be located in a "cgibin" or "cgi" area. This is exposing the mechanism of how you run your server. You change the mechanism (even keeping the content the same ) and whoops - all your URIs change.

For example, take the The National Science Foundation:

NSF Online Documents
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

the main page for starting to look for documents, is clearly not going to be something to trust to being there in a few years. "cgi-bin" and "oldbrowse" and ".pl" all point to bits of how-we-do-it-now. By contrast, if you use the page to find a document, you get first an equally bad

Report of Working Group on Cryptology and Coding Theory
http://www.nsf.gov/cgi-bin/getpub?nsf9814

for the document's index page, but the html document itself by contrast is very much better:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Looking at this one, the "pubs/1998" header is going to give any future archive service a good clue that the old 1998 document classification scheme is in progress. Though in 2098 the document numbers might look different, I can imagine this URI still being valid, and the NSF or whatever carries on the archive not being at all embarrassed about it.

I didn't think URLs have to be persistent - that was URNs.
This is the probably one of the worst side-effects of the URN discussions. Some seem to think that because there is research about namespaces which will be more persistent, that they can be as lax about dangling links as they like as "URNs will fix all that". If you are one of these folks, then allow me to disillusion you.

Most URN schemes I have seen look something like an authority ID followed by either a date and a string you choose, or just a string you choose. This looks very like an HTTP URI. In other words, if you think your organization will be capable of creating URNs which will last, then prove it by doing it now and using them for your HTTP URIs. There is nothing about HTTP which makes your URIs unstable. It is your organization. Make a database which maps document URN to current filename, and let the web server use that to actually retrieve files.

If you have gotten to this point, then unless you have the time and money and contacts to get some software design done, then you might claim the next excuse:

We would like to, but we just don't have the right tools.
Now here is one I can sympathize with. I agree entirely. What you need to do is to have the web server look up a persistent URI in an instant and return the file, wherever your current crazy file system has it stored away at the moment. You would like to be able to store the URI in the file as a check, and constantly keep the database in tune with actuality. You'd like to store the relationships between different versions and translations of the same document, and you'd like to keep an independent record of the checksum to provide a guard against file corruption by accidental error. And web servers just don't come out of the box with these features. When you want to create a new document, your editor asks you for a URI instead of telling you.

You need to be able to change things like ownership, access, archive level security level, and so on, of a document in the URI space without changing the URI.

Too bad. But we'll get there. At W3C we use Jigedit functionality (Jigsaw server used for editing) which does track versions, and we are experimenting with document creation scripts. If you make tools, servers and clients, take note!

This is an outstanding reason, which applies for example to many W3C pages including this one: so do what I say, not what I do.

Why should I care?
When you change a URI on your server, you can never completely tell who will have links to the old URI. They might have made links from regular web pages. They might have bookmarked your page. They might have scrawled the URI in the margin of a letter to a friend.

When someone follows a link and it breaks, they generally lose confidence in the owner of the server. They also are frustrated - emotionally and practically from accomplishing their goal.

Enough people complain all the time about dangling links that I hope the damage is obvious. I hope it also obvious that the reputation damage is to the maintainer of the server whose document vanished.

So what should I do? Designing URIs
It the the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment.

URIs change when there is some information in them which changes. It is critical how you design them. (What, design a URI? I have to design URIs? Yes, you have to think about it.). Designing mostly means leaving information out.

The creation date of the document - the date the URI is issued - is one thing which will not change. It is very useful for separating requests which use a new system from those which use an old system. That is one thing which us good to start a URI with. If a document is in any way dated, even though it will be if interest for generations, then the date is a good starter.

The only exception is a page which is deliberately a "latest" page for, for example, the whole organization or a large part of it.

http://www.pathfinder.com/money/moneydaily/latest/

is the latest "Money daily" column in "Money" magazine. The main reason for not needing the date in this URI is that there is no reason for the persistence of the URI to outlast the magazine. The concept of "today's Money" vanishes if Money goes out of production. If you want to link to the content, you would link to it where it appears separately in the archives as

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Looks good. Assumes that "money" will mean the same thing throughout the life of pathfinder.com. There is a duplication of "98" and an ".html" you don't need but otherwise this looks a strong URI).

What to leave out
Everything! After the creation date, putting any information in the name is asking for trouble one way or another.

Authors name- authorship can change with new versions. People quit organizations and hand things on.
Subject. This is tricky. It always looks good at the time but changes surprisingly fast. I discuss this more below.
Status- directories like "old" and "draft" and so on, not to mention "latest" and "cool" appear all over file systems. Documents change status - or there would be no point in producing drafts. The latest version of a document needs a persistent identifier whatever its status is. Keep the status out of the name.
Access. At W3C we divide the site into "Team access", "Member access" and "Public access". It sounds good, but of course documents start off as team ideas, are discussed with members, and then go public. A shame indeed if every time some document is opened to wider discussion all the old links to it fail! We are switching to a simple date code now.
File name extension. This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension.(how?)
Software mechanisms. Look for "cgi", "exec" and other give-away "look what software we are using" bits in URIs. Anyone want to commit to using perl cgi scripts all their lives? Nope? Cut out the .pl. Read the server manual on how to do it.
Disk name - gimme a break! But I've seen it.

So a better example from our site is simply

http://www.w3.org/1998/12/01/chairs

a report of the minutes of a meeting of W3C chairpeople.

Topics and Classification by subject
I'll go into this danger in more detail as it is one of the more difficult things to avoid. Typically, topics end up in URIs when you classify your documents according to a breakdown of the work you are doing. That breakdown will change. Names for areas will change. At W3C we wanted to change "MarkUp" to "Markup" and then to "HTML" to reflect the actual content of the section. Also, beware that this is often a flat name space. In 100 years are you sure you won't want to reuse anything? We wanted to reuse "History" and "Stylesheets" for example in our short life.

This is a tempting way of organizing a web site - and indeed a tempting way of organizing anything, including the whole web. It is a great medium term solution but has serious drawbacks in the long term

Part of the reasons for this lie in the philosophy of meaning. every term in the language it a potential clustering subject, and each person can have a different idea of what it means. Because the relationships between subjects are web-like rather than tree-like, even for people who agree on a web may pick a different tree representation. These are my (oft repeated) general comments on the dangers of hierarchical classification as a general solution.

Effectively, when you use a topic name in a URI you are binding yourself to some classification. You may in the future prefer a different one. Then, the URI will be liable to break.

A reason for using a topic area as part of the URI is that responsibility for sub-parts of a URI space is typically delegated, and then you need a name for the organizational body - the subdivision or group or whatever - which has responsibility for that sub-space. This is binding your URIs to the organizational structure. It is typically safe only when protected by a date further up the URI (to the left of it): 1998/pics can be taken to mean for your server "what we meant in 1998 by pics", rather than "what in 1998 we did with what we now refer to as pics."

Don't forget the domain name.
Remember that this applies not only to the "path" part of a URI but to the server name. If you have separate servers for some of your stuff, remember that that division will be impossible to change without destroying many many links. Some classic "look what software we are using today" domain names are "cgi.pathfinder.com", "secure", "lists.w3.org". They are made to make administration of the servers easier. Whether it represents divisions in your company, or document status, or access level, or security level, be very, very careful before using more than one domain name for more than one type of document. remember that you can hide many web servers inside one apparent web server using redirection and proxying.

Oh, and do think about your domain name. If your name is not soap, will you want to be referred to as "soap.com" even when you have switched your product line to something else. (With apologies to whoever owns soap.com at the moment).

Conclusion
Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.

See also:

Jacob Nielsen's "Alertbox" rant on the same topic

--------------------------------------------------------------------------------
(back to Etiquette for server administrators, on to Structure of your work)
Footnote
How can I remove the file extensions...
...from my URIs in a practical file-based web server?

If you are using, for example, Apache, you can set it up to do content negotiation. You keep the file extension (such as .png) on the file (eg mydog.png), but refer to the web resource without it. Apache then checks the directory for all files with that name and any extension, and it can also pick the best one out of a set (e.g. GIF and PNG). (You do not have to put different types of file in different directories, in fact the content negotiation won't work if you do.)

Set up your server to do content negotiation
Make references always to the URI without the extension
References which do have the extension on will still work but will not allow your server to select the best of currently available and future formats.

(In fact, mydog, mydog.png and mydog.gif are each valid web resources. mydog is content-type-generic. mydog.png and mydog.gif are content-type-specific.)

Of course, if you are building your own server, then using a database to relate persistent identifiers to their current form is a very clean idea -- though beware the unbounded growth of your database.

Hall of flame -- story 1: Channel 7
During 1999, http://www.whdh.com/stormforce/closings.shtml was a page I found documenting school closings due to snow. An alternative to waiting for them to scroll past the bottom of the TV screen! I put a pointer to it from my home page. Come the firt big storm 2000, and I check the page. It says,

"Closings as of .
There are currently no closings in effect. Please check back when the weather warrants"

Can't be such a big storm. Funny the date is missing. But then if I go to the home page of the site, there is a big button "school closings" which takes me to http://www.whdh.com/stormforce/ which has a list of many closed schools.

Well, maybe they changed the system which got the closings from the definitive list - but they did not need to change the URI.

Hall of flame -- story 2: Microsoft Netmeeting
One of the smarts which came with a growing dependency on the web was that applications could have built-in links back to the manufacturer's web site. This has been used and abused to a great extent, but - you do have to keep the URL the same. Just the other day I tried a link from Microsoft's Netmeeting 2/something client under a menu "Help/Microsoft on the Web/Free stuff" and got an Error 404 - not found response from the server. They have probably fixed it by now...

(c)1998 Tim BL
Historical note: At the end of the 20th century when this was written, "cool" was an epithet of approval particularly among young, indicating trendiness, quality, or appropriateness. In the rush to stake our DNS territory involved the choice of domain name and URI path were sometimes directed more toward apparent "coolness" than toward usefulness or longevity. This note is an attempt to redirect the energy behind the quest for coolness.

March 18, 2006

shtml精简教程

SSI有什么用?
之所以要扯到ssi,是因爲shtml--server-parsed HTML 的首字母缩略词。包含有嵌入式服务器方包含命令的 HTML 文本。在被传送给浏览器之前,服务器会对 SHTML 文档进行完全地读取、分析以及修改。
shtml和asp 有一些相似,以shtml命名的文件里,使用了ssi的一些指令,就像asp中的指令,你可以在SHTML文件中写入SSI指令,当客户端访问这些shtml文件时,
服务器端会把这些SHTML文件进行读取和解释,把SHTML文件中包含的SSI指令解释出来比如:你可以在SHTML文件中用SSI指令引用其他的html文件(#include ),服务器传送给客户端的文件,是已经解释的SHTML不会有SSI指令。它实现了HTML所没有的功能,就是可以实现了动态
的SHTML,可以说是HTML的一种进化吧。像新浪的新闻系统就是这样的,新闻内容是固定的但它上面的广告和菜单等就是用#include引用进来的。

  目前,主要有以下几种用用途:
  1、显示服务器端环境变量<#echo>
  2、将文本内容直接插入到文档中<#include>
  3、显示WEB文档相关信息<#flastmod #fsize> (如文件制作日期/大小等)
  4、直接执行服务器上的各种程序<#exec>(如CGI或其他可执行程序)
  5、设置SSI信息显示格式<#config>(如文件制作日期/大小显示方式)
  高级SSI<XSSI>可设置变量使用if条件语句。
 
使用SSI
  SSI是为WEB服务器提供的一套命令,这些命令只要直接嵌入到HTML文档的注释内容之中即可。如:
  <!--#include file="info.htm"-->
  就是一条SSI指令,其作用是将"info.htm"的内容拷贝到当前的页面中,当访问者来浏览时,会看到其它HTML文档一样显示info.htm其中的内容。
  其它的SSI指令使用形式基本同刚才的举例差不多,可见SSI使用只是插入一点代码而已,使用形式非常简单。
  当然,如果WEB服务器不支持SSI,它就会只不过将它当作注释信息,直接跳过其中的内容;浏览器也会忽略这些信息。
 
如何在我的WEB服务器上配置SSI功能?
  在一些WEB服务器上(如IIS 4.0/SAMBAR 4.2),包含 #include 指令的文件必须使用已被映射到 SSI 解释程序的扩展名;否则,Web 服务器将不会处理该SSI指令;默认情况下,扩展名 .stm、.shtm 和 .shtml 被映射到解释程序(Ssinc.dll)。
  Apache则是根据你的设置情况而定,修改srm.conf如:
  AddType text/x-server-parsed-html .shtml 将只对.shtml扩展名的文件解析SSI指令
  AddType text/x-server-parsed-html .html将对所有HTML文档解析SSI指令
  Netscape WEB服务器直接使用Administration Server(管理服务器)可打开SSI功能。
  Website使用Server Admin程序中的Mapping标签,扩展名添加内容类型为:wwwserver/html-ssi
  Cern服务器不支持SSI,可用SSI诈骗法,到http://sw.cse.bris.ac.uk/WebTools/fakessi.html 上下载一个PERL脚本,即可使你的CERN服务器使用一些SSI指令。(不支持exec指令。)
 
SSI指令基本格式
SSI指令基本格式:
程序代码:

<!-– 指令名称="指令参数">
<!-– 指令名称="指令参数">

程序代码:

<!--#include file="info.htm"-->
<!--#include file="info.htm"-->
说明:
1.<!-- -->是HTML语法中表示注释,当WEB服务器不支持SSI时,会忽略这些信息。
2.#include 为SSI指令之一。
3.file 为include的参数, info.htm为参数值,在本指令中指将要包含的文档名。

注意:

1.<!--与#号间无空格,只有SSI指令与参数间存在空格。
2.上面的标点="",一个也不能少。
3.SSI指令是大小写敏感的,因此参数必须是小写才会起作用。
 
SSI指令使用详解

#echo 示范
作用:
将环境变量插入到页面中。
语法:
程序代码:

<!--#echo var="变量名称"-->
<!--#echo var="变量名称"-->

本文档名称:程序代码:

<!--#echo var="DOCUMENT_NAME"-->
<!--#echo var="DOCUMENT_NAME"-->
现在时间:程序代码:

<!--#echo var="DATE_LOCAL"-->
<!--#echo var="DATE_LOCAL"-->
你的IP地址是程序代码:

<!--#echo var="REMOTE_ADDR"-->
<!--#echo var="REMOTE_ADDR"-->

#include 示范
作用:
将文本文件的内容直接插入到文档页面中。
语法:
程序代码:

<!--#include file="文件名称"-->
<!--#include virtual="文件名称"-->
<!--#include file="文件名称"-->
<!--#include virtual="文件名称"-->
file 文件名是一个相对路径,该路径相对于使用 #include 指令的文档所在的目录。被包含文件可以在同一级目录或其子目录中,但不能在上一级目录中。如表示当前目录下的的nav_head.htm文档,则为file="nav_head.htm"。
virtual 文件名是 Web 站点上的虚拟目录的完整路径。如表示相对于服务器文档根目录下hoyi目录下的nav_head.htm文件;则为file="/hoyi/nav_head.htm"
参数:
file 指定包含文件相对于本文档的位置
virtual 指定相对于服务器文档根目录的位置
注意:
1、文件名称必须带有扩展名。
2、被包含的文件可以具有任何文件扩展名,我觉得直接使用htm扩展名最方便,微软公司推荐使用 .inc 扩展名(这就看你的爱好了)。
示例:
程序代码:

<!--#include file="nav_head.htm"-->将头文件插入到当前页面
<!--#include file="nav_foot.htm"-->将尾文件插入到当前页面
<!--#include file="nav_head.htm"-->将头文件插入到当前页面
<!--#include file="nav_foot.htm"-->将尾文件插入到当前页面

#flastmod 和#fsize 示范
作用: #flastmod 文件最近更新日期
#fsize 文件的长度
语法:
程序代码:

<!--#flastmod file="文件名称"-->
<!--#fsize file="文件名称"-->
<!--#flastmod file="文件名称"-->
<!--#fsize file="文件名称"-->
参数:
file 指定包含文件相对于本文档的位置 如 info.txt 表示当前目录下的的info.txt文档
virtual 指定相对于服务器文档根目录的位置 如 /hoyi/info.txt 表示
注意:
文件名称必须带有扩展名。
示例:
程序代码:

<!--#flastmod file="news.htm"-->
<!--#flastmod file="news.htm"-->
将当前目录下news.htm文件的最近更新日期插插入到当前页面
程序代码:

<!--#fsize file="news.htm"-->
<!--#fsize file="news.htm"-->
将当前目录下news.htm的文件大小入到当前页面
 
#exec 示范
作用:
将某一外部程序的输出插入到页面中。可插入CGI程序或者是常规应用程序的输入,这取决于使用的参数是cmd还是cgi。
语法:
程序代码:

<!--#exec cmd="文件名称"-->
<!--#exec cgi="文件名称"-->
<!--#exec cmd="文件名称"-->
<!--#exec cgi="文件名称"-->
参数:
cmd 常规应用程序
cgi CGI脚本程序
示例:
程序代码:

<!--#exec cmd="cat /etc/passwd"-->将会显示密码文件
<!--#exec cmd="dir /b"-->将会显示当前目录下文件列表
<!--#exec cgi="/cgi-bin/gb.cgi"-->将会执行CGI程序gb.cgi。
<!--#exec cgi="/cgi-bin/access_log.cgi"-->将会执行CGI程序access_log.cgi。
<!--#exec cmd="cat /etc/passwd"-->将会显示密码文件
<!--#exec cmd="dir /b"-->将会显示当前目录下文件列表
<!--#exec cgi="/cgi-bin/gb.cgi"-->将会执行CGI程序gb.cgi。
<!--#exec cgi="/cgi-bin/access_log.cgi"-->将会执行CGI程序access_log.cgi。
注意:
从上面的示例可以看出,这个指令相当方便,但是也存在安全问题。
禁止方法:
.Apache,将access.conf中的"Options Includes ExecCGI"这行代码删除;
.在IIS中,要禁用 #exec 命令,可修改 SSIExecDisable 元数据库;

#config
作用: 指定返回给客户端浏览器的错误信息、日期和文件大小的格式。
语法:
程序代码:

<!--#config errmsg="自定义错误信息"-->
<!--#config sizefmt="显示单位"-->
<!--#config timefmt="显示格式"-->
<!--#config errmsg="自定义错误信息"-->
<!--#config sizefmt="显示单位"-->
<!--#config timefmt="显示格式"-->
参数:
errmsg 自定义SSI执行错误信息,可以为任何你喜欢的方式。
sizefmt 文件大小显示方式,默认为字节方式("bytes")可以改为千字节方式("abbrev")
timefmt 时间显示方式,最灵活的配置属性。
示例: 显示一个不存在文件的大小
程序代码:

<!--#config errmsg="服务器执行错误,请联系管理员,谢谢!"-->
<!--#fsize file="不存在的文件.htm"-->
<!--#config errmsg="服务器执行错误,请联系管理员,谢谢!"-->
<!--#fsize file="不存在的文件.htm"-->
以千字节方式显示文件大小
程序代码:

<!--#config sizefmt="abbrev"-->
<!--#fsizefile="news.htm"-->
<!--#config sizefmt="abbrev"-->
<!--#fsizefile="news.htm"-->
以特定的时间格式显示时间
程序代码:

<!--#config timefmt="%Y年/%m月%d日 星期%W 北京时间%H:%M:%s,%Y年已过去了%j天 今天是%Y年的第%U个星期"-->
<!--#echo var="DATE_LOCAL"--> 显示今天是星期几,几月,时区
<!--#config timefmt="今天%A, %B ,服务器时区是 %z,是"-->
<!--#echo var="DATE_LOCAL"-->
<!--#config timefmt="%Y年/%m月%d日 星期%W 北京时间%H:%M:%s,%Y年已过去了%j天 今天是%Y年的第%U个星期"-->
<!--#echo var="DATE_LOCAL"--> 显示今天是星期几,几月,时区
<!--#config timefmt="今天%A, %B ,服务器时区是 %z,是"-->
<!--#echo var="DATE_LOCAL"-->

XSSI
XSSI(Extended SSI)是一组高级SSI指令,内置于Apache 1.2或更高版本的mod-include模块之中。
其中可利用的的指令有:
#printenv
#set
#if
#printenv
作用: 显示当前存在于WEB服务器环境中的所有环境变量。
语法:程序代码:

<!--#printenv-->
<!--#printenv-->
参数:无
示例:
程序代码:

<!--#printenv-->
<!--#printenv-->

#set
作用:可给变量赋值,以用于后面的if语句。
语法:程序代码:

<!--#set var="变量名"value="变量值"-->
<!--#set var="变量名"value="变量值"-->
参数:无
示例: 程序代码:

<!--#set var="color"value="红色"-->
<!--#set var="color"value="红色"-->

#if
作用: 创建可以改变数据的页面,这些数据根据使用if语句时计算的要求予以显示。
语法: 程序代码:

<!--#if expr="$变量名=\"变量值A\""-->
显示内容
<!--#elif expr="$变量名=\"变量值B\""-->
显示内容
<!--#else-->
显示内容
<!--#endif"-->
<!--#if expr="$变量名=\"变量值A\""-->
显示内容
<!--#elif expr="$变量名=\"变量值B\""-->
显示内容
<!--#else-->
显示内容
<!--#endif"-->
示例:
程序代码:

<!--#if expr="$SERVER_NAME=\"www.e3i5.com\""-->
欢迎光临E代时光。
<!--#elif expr="$SERVER_NAME=\"bbs.e3i5.com\"" -->
欢迎光临E代时光论坛。
<!--#else-->
欢迎光临E代时光。
<!--#endif"-->
<!--#if expr="$SERVER_NAME=\"www.e3i5.com\""-->
欢迎光临E代时光。
<!--#elif expr="$SERVER_NAME=\"bbs.e3i5.com\"" -->
欢迎光临E代时光论坛。
<!--#else-->
欢迎光临E代时光。
<!--#endif"-->
注意: 用于前面指令中的反斜杠,是用来代换内部的引号,以便它们不会被解释为结束表达式。不可省略。

1、Config命令

  Config命令主要用于修改SSI的默认设置。其中:

  Errmsg:设置默认错误信息。为了能够正常的返回用户设定的错误信息,在HTML文件中Errmsg参数必须被放置在其它SSI命令的前面,否则客户端只能显示默认的错误信息,而不是由用户设定的自定义信息。

    <!--#config errmsg="Error! Please email webmaster@mydomain.com -->

  Timefmt:定义日期和时间的使用格式。Timefmt参数必须在echo命令之前使用。

    <!--#config timefmt="%A, %B %d, %Y"-->
    <!--#echo var="LAST_MODIFIED" -->

  显示结果为:

    Wednesday, April 12, 2000

  也许用户对上例中所使用的%A %B %d感到很陌生,下面我们就以表格的形式总结一下SSI中较为常用的一些日期和时间格式。

  Sizefmt:决定文件大小是以字节、千字节还是兆字节为单位表示。如果以字节为单位,参数值为"bytes";对于千字节和兆字节可以使用缩写形式。同样,sizefmt参数必须放在fsize命令的前面才能使用。

    <!--#config sizefmt="bytes" -->
    <!--#fsize file="index.html" -->

  2、Include命令

  Include命令可以把其它文档中的文字或图片插入到当前被解析的文档中,这是整个SSI的关键所在。通过Include命令只需要改动一个文件就可以瞬间更新整个站点!

  Include命令具有两个不同的参数:

  Virtual:给出到服务器端某个文档的虚拟路径。例如:

    <!--#include virtual="/includes/header.html" -->

  File:给出到当前目录的相对路径,其中不能使用"../",也不能使用绝对路径。例如:

    <!--#include file="header.html" -->

  这就要求每一个目录中都包含一个header.html文件。

  3、Echo命令

  Echo命令可以显示以下各环境变量:

  DOCUMENT_NAME:显示当前文档的名称。

    <!--#echo var="DOCUMENT_NAME" -->

显示结果为:

    index.html

  DOCUMENT_URI:显示当前文档的虚拟路径。例如:

    <!--#echo var="DOCUMENT_URI" -->

  显示结果为:

    /YourDirectory/YourFilename.html

  随着网站的不断发展,那些越来越长的URL地址肯定会让人头疼。如果使用SSI,一切就会迎刃而解。因为我们可以把网站的域名和SSI命令结合在一起显示完整的URL,即:

  http://YourDomain<!--#echo var="DOCUMENT_URI" -->

  QUERY_STRING_UNESCAPED:显示未经转义处理的由客户端发送的查询字串,其中所有的特殊字符前面都有转义符"\"。例如:

  <!--#echo var="QUERY_STRING_UNESCAPED" -->

  DATE_LOCAL:显示服务器设定时区的日期和时间。用户可以结合config命令的timefmt参数,定制输出信息。例如:

  <!--#config timefmt="%A, the %d of %B, in the year %Y" -->
 <!--#echo var="DATE_LOCAL" -->

  显示结果为:

  Saturday, the 15 of April, in the year 2000

  DATE_GMT:功能与DATE_LOCAL一样,只不过返回的是以格林尼治标准时间为基准的日期。例如:

  <!--#echo var="DATE_GMT" -->

  LAST_MODIFIED:显示当前文档的最后更新时间。同样,这是SSI中非常实用的一个功能,只要在HTML文档中加入以下这行简单的文字,就可以在页面上动态的显示更新时间。

  <!--#echo var="LAST_MODIFIED" -->

  CGI环境变量

  除了SSI环境变量之外,echo命令还可以显示以下CGI环境变量:

    SERVER_SOFTWARE:显示服务器软件的名称和版本。例如:
    <!--#echo var="SERVER_SOFTWARE" -->
    SERVER_NAME: 显示服务器的主机名称,DNS别名或IP地址。例如:
    <!--#echo var="SERVER_NAME" -->
    SERVER_PROTOCOL:显示客户端请求所使用的协议名称和版本,如HTTP/1.0。例如:
    <!--#echo var="SERVER_PROTOCOL" -->
    SERVER_PORT:显示服务器的响应端口。例如:
    <!--#echo var="SERVER_PORT" -->
    REQUEST_METHOD:显示客户端的文档请求方法,包括GET, HEAD, 和POST。例如:
    <!--#echo var="REQUEST_METHOD" -->
    REMOTE_HOST:显示发出请求信息的客户端主机名称。
    <!--#echo var="REMOTE_HOST" -->
    REMOTE_ADDR:显示发出请求信息的客户端IP地址。
    <!--#echo var="REMOTE_ADDR" -->
    AUTH_TYPE:显示用户身份的验证方法。
    <!--#echo var="AUTH_TYPE" -->
    REMOTE_USER:显示访问受保护页面的用户所使用的帐号名称。
    <!--#echo var="REMOTE_USER" -->
4、Fsize:显示指定文件的大小,可以结合config命令的sizefmt参数定制输出格式。

    <!--#fsize file="index_working.html" -->

  5、Flastmod:显示指定文件的最后修改日期,可以结合config 命令的timefmt参数控制输出格式。

    <!--#config timefmt="%A, the %d of %B, in the year %Y" -->
    <!--#flastmod file="file.html" -->

  这里,我们可以利用flastmod参数显示出一个页面上所有链接页面的更新日期。方法如下:

    <!--#config timefmt=" %B %d, %Y" -->
    <A HREF="/directory/file.html">File</A>
    <!--#flastmod virtual="/directory/file.html" -->
    <A HREF="/another_directory/another_file.html">Another File</A>
    <!--#flastmod virtual="/another_directory/another_file.html" -->
  显示结果为:
    File April 19, 2000
    Another File January 08, 2000

  6、Exec

  Exec命令可以执行CGI脚本或者shell命令。使用方法如下:

   Cmd:使用/bin/sh执行指定的字串。如果SSI使用了IncludesNOEXEC选项,则该命令将被屏蔽。

   Cgi:可以用来执行CGI脚本。例如,下面这个例子中使用服务端cgi-bin目录下的counter.pl脚本程序在每个页面放置一个计数器:

   <!--#exec cgi="/cgi-bin/counter.pl" -->

March 12, 2006

Apache的ReWrite

Apache的mod_rewrite是提供了强大URL操作的杀手级的模块,可以实现几乎所有你梦想的URL操作类型,其代价是你必须接受其复杂性,因为mod_rewrite的主要障碍就是初学者不容易理解和运用,即使是Apache专家有时也会发掘出mod_rewrite的新用途。

换句话说:对mod_rewrite,或者是打退堂鼓永不再用,或者是喜欢它并一生受用。

ReWrite可以应用在以下方面或者解决以下问题:
URL的规划
规范的URL
说明:
在有些网站服务器上,一个资源会拥有多个URL,在实际应用和发布中应该被使用的是规范的URL,其他的则是简写或者是内部使用的。无论用户在请求中使用什么形式的URL,他最终看见的都应该是规范的URL。

说明:
在有些网站服务器上,一个资源会拥有多个URL,在实际应用和发布中应该被使用的是规范的URL,其他的则是简写或者是内部使用的。无论用户在请求中使用什么形式的URL,他最终看见的都应该是规范的URL。

方案:
对所有的不规范的URL执行一个外部的HTTP重定向,以改变它在浏览器地址栏中的显示及其后继的请求。下例中的规则集用规范的/u/user替换/~user,并修正了/u/user所遗漏的后缀的斜杠。

代码:
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2 [R]
RewriteRule ^/([uge])/([^/]+)$ /$1/$2/ [R]

规范的主机名
说明:
...
方案:
代码:
RewriteCond % !^fully.qualified.domain.name [NC]
RewriteCond % !^$
RewriteCond % !^80$
RewriteRule ^/(.*) http://fully.qualified.domain.name:%/$1 [L,R]
RewriteCond % !^fully.qualified.domain.name [NC]
RewriteCond % !^$
RewriteRule ^/(.*) http://fully.qualified.domain.name/$1 [L,R]

被移动过的DocumentRoot
说明:
通常,网站服务器的DocumentRoot直接对应于URL"/",但是,它常常不是处于最高一级,而可能只是众多数据池中的一个实体。比如,在Intranet站点中,有/e/www/(WWW的主页)、/e/sww/ (Intranet的主页)等等,而DocumentRoot指向了/e/www/,则必须保证此数据池中的所有内嵌的图片和其他元素对后继请求有效。

方案:
只须重定向URL /到/e/www/即可。这个方案看起来很简单,但只是有了mod_rewrite模块的支持,它才简单,因为传统的URL Aliases机制(由mod_alias及其相关模块提供)只是作了一个前缀匹配,DocumentRoot是一个对所有URL的前缀,因而无法实现这样的重定向。而用mod_rewrite的确很简单:

代码:
RewriteEngine on
RewriteRule ^/$ /e/www/ [R]

后缀斜杠的问题
说明:
每个网管对引用目录后缀斜杠的问题都有一本苦经,如果遗漏了,服务器会产生一个错误,因为如果请求是/~quux/foo而不是/~quux/foo/,服务器会去找一个叫foo的文件,而它是一个目录,所以就报错了。事实上,大多数情况下,它自己会试图修正这个错误,但是有时候需要你手工纠正,比如,在重写了许多CGI脚本中的复杂的URL以后。

方案:
解决这个微妙问题的方案是让服务器自动添加后缀的斜杠。对此,必须使用一个外部的重定向,使浏览器正确地处理后继的对诸如图片的请求。如果仅仅作一个内部的重写,可能只对目录页面有效,而对内嵌有使用相对URL的图片的页面则无效,因为浏览器有请求内嵌目标的可能。比如,如果不用外部重定向,/~quux/foo/index.html页面中对image.gif的请求,其结果将是/~quux/image.gif!。

所以,应该这样写:

代码:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo$ foo/ [R]

又懒又疯狂的做法是把这些写入其宿主目录中的顶级.htaccess中,但是须注意,如此会带来一些处理上的开销。

代码:
RewriteEngine on
RewriteBase /~quux/
RewriteCond % -d
RewriteRule ^(.+[^/])$ $1/ [R]

集群网站的同类URL规划
说明:
我们希望在一个Intranet集群网站中,对所有WWW服务器建立一个同类的一致性的URL规划,也就是,所有的URL(对单个服务器来说,是本地的依赖于此服务器的!)是独立于服务器的!我们需要的是一个具有独立于服务器的一致性规划的WWW名称空间,即,URL不需要包含正确的物理的目标服务器,而由集群本身来自动定位物理的目标主机。

方案:
首先,目标服务器的信息来自(产生)于包含有用户、组以及实体的外部地图,其格式形如:

代码:
user1 server_of_user1
user2 server_of_user2
: :

这些信息被存入map.xxx-to-host文件。其次,如果URL在一个服务器上无效,需要引导所有的服务器重定向URL

代码:
/u/user/anypath
/g/group/anypath
/e/entity/anypath

代码:
http://physical-host/u/user/anypath
http://physical-host/g/group/anypath
http://physical-host/e/entity/anypath

以下规则集依靠地图文件来完成这个操作(假定,如果一个用户在地图中没有对应的项,则使用server0为默认服务器):

代码:
RewriteEngine on

RewriteMap user-to-host txt:/path/to/map.user-to-host
RewriteMap group-to-host txt:/path/to/map.group-to-host
RewriteMap entity-to-host txt:/path/to/map.entity-to-host

RewriteRule ^/u/([^/]+)/?(.*) http://$/u/$1/$2
RewriteRule ^/g/([^/]+)/?(.*) http://$/g/$1/$2
RewriteRule ^/e/([^/]+)/?(.*) http://$/e/$1/$2

RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/
RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3

移动宿主目录到不同的网站服务器
说明:
通常,许多网管在建立一个新的网站服务器时,都会有这样的要求:重定向一个网站服务器上的所有宿主目录到另一个网站服务器。

方案:
很简单,用mod_rewrite。在老的网站服务器上重定向所有的URL /~user/anypath到http://newserver/~user/anypath。

代码:
RewriteEngine on
RewriteRule ^/~(.+) http://newserver/~$1 [R,L]

结构化的宿主目录
说明:
一些拥有几千个用户的网站通常都使用结构化的宿主目录规划,即,每个宿主目录位于一个带有特定前缀比如其用户名的第一个字符的子目录下。那么,/~foo/anypath代表/home/f/foo/.www/anypath,而/~bar/anypath代表/home/b/bar/.www/anypath。

方案:
可以使用下列规则集来扩展~以达到上述目的。

代码:
RewriteEngine on
RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/.www$3

文件系统的重组
说明:
这是一个不加雕琢的例子:一个大量使用针对目录的规则集以实现平滑观感,而从来不用调整数据结构的杀手级的应用。背景:net.sw从1992年开始,存放了我收集的免费的有效的Unix软件包。它是我的爱好也是我的工作,因为在学习计算机科学的同时,业余时间还做了多年的系统和网络的管理员。每周我都需要整理软件,因而建立了一个层次很深的目录结构来存放各种软件包:

代码:
drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/
drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/
drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/
drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/
drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/
drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/
drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/
drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/
drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/
drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/
drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/
drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/
drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/
drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/
drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/
drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/

1996年7月,我决定通过一个漂亮的Web接口公开我的收藏。“漂亮”是指提供一个接口以直接浏览整个目录结构,同时不对这个结构做任何改变 - 甚至也不在结构顶部放置CGI脚本。为什么呢?因为这个结构还要能够被FTP访问,而且我不希望其中有任何Web或者CGI的成分。

方案:
这个方案分为两个部分:第一个部分,是用于在空闲时间建立所有目录页面的CGI脚本集。我把它们放在/e/netsw/.www/,如下:

代码:
-rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl
drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/
-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE
-rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO
-rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html
-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl
-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi
-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi
drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi
-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi
-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi
-rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst

其中的DATA/子目录包含了上述目录结构,即实在的net.sw,由rdist在需要的时候自动更新。第二个部分的遗留问题是:如何连接这两个结构为一个平滑观感的URL树?我希望在运行适当的CGI脚本而使用各种URL的时候,使用户感觉不到DATA/目录的存在。方案如下:首先,我把下列配置放在服务器上DocumentRoot中的针对目录的配置文件里,以重写公布的URL /net.sw/ 为内部路径 /e/netsw:

代码:
RewriteRule ^net.sw$ net.sw/ [R]
RewriteRule ^net.sw/(.*)$ e/netsw/$1

第一条规则是针对遗漏后缀斜杠的请求的!第二条规则才是真正实现功能的。接着,就是放在针对目录的配置文件/e/netsw/.www/.wwwacl中的杀手级的配置了:

代码:
Options ExecCGI FollowSymLinks Includes MultiViews

RewriteEngine on

# we are reached via /net.sw/ prefix
RewriteBase /net.sw/

# first we rewrite the root dir to
# the handling cgi script
RewriteRule ^$ netsw-home.cgi [L]
RewriteRule ^index.html$ netsw-home.cgi [L]

# strip out the subdirs when
# the browser requests us from perdir pages
RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]

# and now break the rewriting for local files
RewriteRule ^netsw-home.cgi.* - [L]
RewriteRule ^netsw-changes.cgi.* - [L]
RewriteRule ^netsw-search.cgi.* - [L]
RewriteRule ^netsw-tree.cgi$ - [L]
RewriteRule ^netsw-about.html$ - [L]
RewriteRule ^netsw-img/.*$ - [L]

# anything else is a subdir which gets handled
# by another cgi script
RewriteRule !^netsw-lsdir.cgi.* - [C]
RewriteRule (.*) netsw-lsdir.cgi/$1

阅读提示:

注意前半部分中的标志L(最后),和无对应项('-')
注意后半部分中的符号!(非),和标志C (链)
注意最后一条规则的全匹配模式
代码:
NCSA imagemap和Apache mod_imap
说明:
许多人都希望在从NCSA网站服务器向较现代的Apache网站服务器转移中实现平滑过渡,即希望老的NCSA imagemap程序能在Apache的较现代的mod_imap支持下正常运作。但问题在于,到处都是通过/cgi-bin/imagemap/path/to/page.map引用imagemap程序的连接,而在Apache下,应该写成/path/to/page.map。

方案:
使用全局规则在空闲时间去除所有这些请求的前缀:

代码:
RewriteEngine on
RewriteRule ^/cgi-bin/imagemap(.*) $1 [PT]

在多个目录中搜索页面
说明:
有时会有必要使网站服务器在多个目录中搜索页面,对此,MultiViews或者其他技术无能为力。

方案:
编制一个明确的规则集以搜索目录中的文件。

代码:
RewriteEngine on

# first try to find it in custom/...
# ...and if found stop and be happy:
RewriteCond /your/docroot/dir1/% -f
RewriteRule ^(.+) /your/docroot/dir1/$1 [L]

# second try to find it in pub/...
# ...and if found stop and be happy:
RewriteCond /your/docroot/dir2/% -f
RewriteRule ^(.+) /your/docroot/dir2/$1 [L]

# else go on for other Alias or ScriptAlias directives,
# etc.
RewriteRule ^(.+) - [PT]

按照URL的片段设置环境变量
说明:
如果希望保持请求之间的状态信息,但又不希望使用CGI来包装所有页面,而只通过分离URL中的有用信息来编码。

方案:
可以用一个规则集来分离出状态信息,并设置环境变量以备此后用于XSSI或CGI。如此,一个/foo/S=java/bar/的URL会被解析为/foo/bar/,而环境变量STATUS则被设置为"java"。

代码:
RewriteEngine on
RewriteRule ^(.*)/S=([^/]+)/(.*) $1/$3 [E=STATUS:$2]

虚拟用户主机
说明:
如果需要为用户username支持一个www.username.host.domain.com的主页,但不是用在此机器上建虚拟主机的方法,而是用仅在此机器上增加一个DNS记录的方法实现。

方案:
对HTTP/1.0的请求,这是无法实现的;但是对HTTP/1.1的在HTTP头中包含有主机名的请求,可以用以下规则集来内部地重写http://www.username.host.com/anypath为/home/username/anypath:

代码:
RewriteEngine on
RewriteCond % ^www.[^.]+.host.com$
RewriteRule ^(.+) %$1 [C]
RewriteRule ^www.([^.]+).host.com(.*) /home/$1$2

为外来访问者重定向宿主目录
说明:
对不是来自本地域ourdomain.com的外来访问者的请求,重定向其宿主目录URL到另一个网站服务器www.somewhere.com,有时这种做法也会用在虚拟主机的上下文中。

方案:
只须一个重写条件:

代码:
RewriteEngine on
RewriteCond % !^.+.ourdomain.com$
RewriteRule ^(/~.+) http://www.somewhere.com/$1 [R,L]

重定向失败的URL到其他网站服务器
说明:
如何重写URL以重定向对网站服务器A的失败请求到服务器B,是一个常见的问题。一般,可以用Perl写的CGI脚本通过ErrorDocument来解决,此外,还有mod_rewrite方案。但是须注意,这种方法的执行效率不如用ErrorDocument的CGI脚本!

方案:
第一种方案,有最好的性能而灵活性欠佳,出错概率小所以安全:

代码:
RewriteEngine on
RewriteCond /your/docroot/% !-f
RewriteRule ^(.+) http://webserverB.dom/$1

但是其问题在于,它只对位于DocumentRoot中的页面有效。虽然可以增加更多的条件(比如同时还处理宿主目录,等等),但是还有一个更好的方法:

代码:
RewriteEngine on
RewriteCond % !-U
RewriteRule ^(.+) http://webserverB.dom/$1

这种方法使用了mod_rewrite提供的“向前参照(look-ahead)”的功能,是一种对所有URL类型都有效而且安全的方法。但是,对网站服务器的性能会有影响,所以如果网站服务器有一个强大的CPU,那就用这个方法。而在慢速机器上,可以用第一种方法,或者用性能更好的ErrorDocument CGI脚本。

扩展的重定向
说明:
有时候,我们会需要更多的对重定向URL的(有关字符转义机制方面的)控制。通常,Apache内核中的URL转义函数uri_escape()同时还会对anchor转义,即,类似"url#anchor"的URL,因此,你不能用mod_rewrite对此类URL直接重定向。那么如何实现呢?

方案:
必须用NPH-CGI脚本使它自己重定向,因为对NPH(non-parseable headers [无须解析的HTTP头])不会发生转义操作。首先,在针对服务器的配置中(应该位于所有重写规则的最后),引入一种新的URL类型xredirect::

代码:
RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1
[T=application/x-httpd-cgi,L]

以强制所有带xredirect:前缀的URL被传送到如下的nph-xredirect.cgi程序:

代码:
#!/path/to/perl
##
## nph-xredirect.cgi -- NPH/CGI script for extended redirects
## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##

$| = 1;
$url = $ENV;

print "HTTP/1.0 302 Moved Temporarilyn";
print "Server: $ENVn";
print "Location: $urln";
print "Content-type: text/htmln";
print "n";
print "n";
print "n";
print "n";
print "n";
print "n";
print "
Moved Temporarily (EXTENDED)
n";
print "The document has moved here.
n";
print "n";
print "n";

##EOF##

这是一种可以重定向所有URL类型的方法,包括不被mod_rewrite直接支持的类型。所以,还可以这样重定向news:newsgroup:

代码:
RewriteRule ^anyurl xredirect:news:newsgroup

注意:无须对上述规则加[R]或[R,L],因为xredirect:会在稍后被其特殊的传送规则扩展。
文档访问的多路复用
说明:
你知道http://www.perl.com/CPAN的CPAN(Comprehensive Perl Archive Network)吗?它实现了一个重定向以提供,全世界的CPAN镜像中离访问者最近的一个FTP站点,也可以称之为FTP访问多路复用服务。CPAN是通过CGI脚本实现的,那么用mod_rewrite如何实现呢?

方案:
首先,我们注意到mod_rewrite从3.0.0版本开始,还可以重写"ftp:"类型。其次,对客户端顶级域名的路径最近的求取可以用RewriteMap实现。利用链式规则集,并用顶级域名作为查找多路复用地图的键,可以这样做:

代码:
RewriteEngine on
RewriteMap multiplex txt:/path/to/map.cxan
RewriteRule ^/CxAN/(.*) %::$1 [C]
RewriteRule ^.+.([a-zA-Z]+)::(.*)$ $$2 [R,L]

##
## map.cxan -- Multiplexing Map for CxAN
##

de ftp://ftp.cxan.de/CxAN/
uk ftp://ftp.cxan.uk/CxAN/
com ftp://ftp.cxan.com/CxAN/
:
##EOF##

依赖于时间的重写
说明:
在页面内容依时间不同而变化的场合,比如重定向特定页面,许多网管仍然采用CGI脚本的方法,如何用mod_rewrite来实现呢?

方案:
有许多类似TIME_xxx的变量可以用在重写条件中,利用STRING和=STRING的类型比较,并加以连接,就可以实现依赖于时间的重写:

代码:
RewriteEngine on
RewriteCond %% >0700
RewriteCond %% <1900
RewriteRule ^foo.html$ foo.day.html
RewriteRule ^foo.html$ foo.night.html

此例使URL foo.html在07:00-19:00时指向foo.day.html,而在其余时间,则指向foo.night.html,对主页是一个不错的功能...

对YYYY过渡为XXXX的向前兼容
说明:
在转变了大批.html文件为.phtml,使文档.YYYY过渡成为文档.XXXX后,如何保持URL的向前兼容(仍然虚拟地存在)?

方案:
只须按基准文件名重写,并测试带有新的扩展名的文件是否存在,如果存在,则用新的,否则,仍然用原来的。

代码:
# backward compatibility ruleset for
# rewriting document.html to document.phtml
# when and only when document.phtml exists
# but no longer document.html
RewriteEngine on
RewriteBase /~quux/
# parse out basename, but remember the fact
RewriteRule ^(.*).html$ $1 [C,E=WasHTML:yes]
# rewrite to document.phtml if exists
RewriteCond %.phtml -f
RewriteRule ^(.*)$ $1.phtml [S=1]
# else reverse the previous basename cutout
RewriteCond % ^yes$
RewriteRule ^(.*)$ $1.html

内容的处理
新旧URL(内部的)
说明:
假定已经把文件bar.html改名为foo.html,需要对老的URL向前兼容,即让用户仍然可以使用老的URL,而感觉不到文件被改名了。

方案:
通过以下规则内部地重写老的URL为新的:

代码:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo.html$ bar.html

新旧URL(外部的)
说明:
仍然假定已经把文件bar.html改名为foo.html,需要对老的URL向前兼容,但是要让用户得到文件被改名的暗示,即,其浏览器的地址栏中显示的是新的URL。

方案:
作一个HTTP的强制重定向以改变浏览器和用户界面上的显示:

代码:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo.html$ bar.html [R]

依赖于浏览器的内容
说明:
至少对重要的顶级页面,有时候有必要提供依赖于浏览器的最佳的内容,即对最新的Netscape提供最大化的版本,对Lynx提供最小化的版本,而对其他的浏览器则提供一个功能一般的版本。

方案:
对此,内容协商无能为力,因为浏览器不提供其那种形式的类型,所以只能在HTTP头"User-Agent"上想办法。以下规则集可以完成这个操作:如果HTTP头"User-Agent"以"Mozilla/3"开头,则页面foo.html被重写为foo.NS.html,而后重写操作终止;如果是"Lynx"或者版本号为1和2的"Mozilla",则重写为foo.20.html;而其他所有的浏览器收到的页面则是foo.32.html:

代码:
RewriteCond % ^Mozilla/3.*
RewriteRule ^foo.html$ foo.NS.html [L]

RewriteCond % ^Lynx/.* [OR]
RewriteCond % ^Mozilla/[12].*
RewriteRule ^foo.html$ foo.20.html [L]

RewriteRule ^foo.html$ foo.32.html [L]

动态镜像
说明:
假定,需要在我们的名称空间里加入其他远程主机的页面。对FTP服务器,可以用mirror程序以在本地机器上维持一个对远程数据的最新的拷贝;对网站服务器,可以用类似的用于HTTP的webcopy程序。但这两种技术都有一个主要的缺点:此本地拷贝必须通过这个程序的执行来更新。所以,比较好的方法是,不采用静态镜像,而采用动态镜像,即,在有数据请求时自动更新(远程主机上更新的数据)。

方案:
为此,使用Proxy Throughput功能(flag [P]),以映射远程页面甚至整个远程网络区域到我们的名称空间:

代码:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]

RewriteEngine on
RewriteBase /~quux/
RewriteRule ^usa-news.html$ http://www.quux-corp.com/news/index.html [P]

反向动态镜像
说明:
...
方案:
代码:
RewriteEngine on
RewriteCond /mirror/of/remotesite/$1 -U
RewriteRule ^http://www.remotesite.com/(.*)$ /mirror/of/remotesite/$1

通过Intranet取得丢失的数据
说明:
这是一种在受防火墙保护的(内部的)Intranet(www2.quux-corp.dom)上保存和维护实际数据,而虚拟地运行企业级(外部的)Internet网站服务器(www.quux-corp.dom)的巧妙的方法。这种方法是外部服务器在空闲时间从内部服务器取得被请求的数据。

方案:
首先,必须确保防火墙对内部服务器的保护,并只允许此外部服务器取得数据。对包过滤(packet-filtering)防火墙,可以如下制定防火墙规则:

代码:
ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
DENY Host * Port * --> Host www2.quux-corp.dom Port 80

按你的实际配置,只要对上例稍作调整即可。接着,建立通过代理后台获取丢失数据的mod_rewrite规则:

代码:
RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2
RewriteCond % !-f
RewriteCond % !-d
RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]

负载的均衡
说明:
如何均衡www.foo.com的负载到www[0-5].foo.com(一共是6个服务器)?

方案:
这个问题有许多可能的解决方案,在此,我们讨论通称为“基于DNS(DNS-based)的”方案,和特殊的使用mod_rewrite的方案:

DNS循环(DNS Round-Robin)
最简单的方法是用BIND的DNS循环特性,只要按惯例设置www[0-9].foo.com的DNS的A(地址)记录,如:

代码:
www0 IN A 1.2.3.1
www1 IN A 1.2.3.2
www2 IN A 1.2.3.3
www3 IN A 1.2.3.4
www4 IN A 1.2.3.5
www5 IN A 1.2.3.6

然后,增加以下各项:

代码:
www IN CNAME www0.foo.com.
IN CNAME www1.foo.com.
IN CNAME www2.foo.com.
IN CNAME www3.foo.com.
IN CNAME www4.foo.com.
IN CNAME www5.foo.com.
IN CNAME www6.foo.com.

注意,上述看起来似乎是错误的,但事实上,它的确是BIND中的一个预期的特性,而且也可以这样用。无论如何,现在www.foo.com已经被解析,BIND可以给出www0-www6 - 虽然每次在次序上会有轻微的置换/循环,客户端的请求可以被分散到各个服务器。可是,这并不是一个优秀的负载均衡方案,因为,DNS解析信息可以被网络中其他名称服务器缓冲,而一旦www.foo.com被解析为wwwN.foo.com,则其后继请求都将被送往www.foo.com。但是最终结果是正确的,因为请求的总量的确被分散到各个服务器了

DNS 负载均衡
一种成熟的基于DNS的负载均衡方法是使用http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html的lbnamed程序,它是一个Perl 5程序,带有若干辅助工具,实现了真正的基于DNS的负载均衡。

代理吞吐循环(Proxy Throughput Round-Robin)
这是一个使用mod_rewrite及其代理吞吐特性的方法。首先,在DNS记录中,将www0.foo.com固定为www.foo.com,如下:

代码:
www IN CNAME www0.foo.com.

其次,将www0.foo.com转换为一个专职代理服务器,即,由这个机器把所有到来的URL通过内部代理分散到另外5个服务器(www1-www5)。为此,必须建立一个规则集,对所有URL调用一个负载均衡脚本lb.pl。

代码:
RewriteEngine on
RewriteMap lb prg:/path/to/lb.pl
RewriteRule ^/(.+)$ $ [P,L]

以下是lb.pl:

代码:
#!/path/to/perl
##
## lb.pl -- load balancing script
##

$| = 1;

$name = "www"; # the hostname base
$first = 1; # the first server (not 0 here, because 0 is myself)
$last = 5; # the last server in the round-robin
$domain = "foo.dom"; # the domainname

$cnt = 0;
while () {
$cnt = (($cnt+1) % ($last+1-$first));
$server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
print "http://$server/$_";
}

##EOF##

最后的说明:这样有用吗?www0.foo.com似乎也会超载呀?答案是:没错,它的确会超载,但是它超载的仅仅是简单的代理吞吐请求!所有诸如SSI、CGI、ePerl等等的处理完全是由其他机器完成的,这个才是要点。
硬件/TCP循环
还有一个硬件解决方案。Cisco有一个叫LocalDirector的东西,实现了TCP/IP层的负载均衡,事实上,它是一个位于网站集群前端的电路级网关。如果你有足够资金而且的确需要高性能的解决方案,那么可以用这个。

反向代理
说明:
...
方案:
代码:
##
## apache-rproxy.conf -- Apache configuration for Reverse Proxy Usage
##

# server type
ServerType standalone
Listen 8000
MinSpareServers 16
StartServers 16
MaxSpareServers 16
MaxClients 16
MaxRequestsPerChild 100

# server operation parameters
KeepAlive on
MaxKeepAliveRequests 100
KeepAliveTimeout 15
Timeout 400
IdentityCheck off
HostnameLookups off

# paths to runtime files
PidFile /path/to/apache-rproxy.pid
LockFile /path/to/apache-rproxy.lock
ErrorLog /path/to/apache-rproxy.elog
CustomLog /path/to/apache-rproxy.dlog "%t %h -> %e URL: %U"

# unused paths
ServerRoot /tmp
DocumentRoot /tmp
CacheRoot /tmp
RewriteLog /dev/null
TransferLog /dev/null
TypesConfig /dev/null
AccessConfig /dev/null
ResourceConfig /dev/null

# speed up and secure processing

Options -FollowSymLinks -SymLinksIfOwnerMatch
AllowOverride None

# the status page for monitoring the reverse proxy

SetHandler server-status

# enable the URL rewriting engine
RewriteEngine on
RewriteLogLevel 0

# define a rewriting map with value-lists where
# mod_rewrite randomly chooses a particular value
RewriteMap server rnd:/path/to/apache-rproxy.conf-servers

# make sure the status page is handled locally
# and make sure no one uses our proxy except ourself
RewriteRule ^/apache-rproxy-status.* - [L]
RewriteRule ^(http|ftp)://.* - [F]

# now choose the possible servers for particular URL types
RewriteRule ^/(.*.(cgi|shtml))$ to://$/$1 [S=1]
RewriteRule ^/(.*)$ to://$/$1

# and delegate the generated URL by passing it
# through the proxy module
RewriteRule ^to://([^/]+)/(.*) http://$1/$2 [E=SERVER:$1,P,L]

# and make really sure all other stuff is forbidden
# when it should survive the above rules...
RewriteRule .* - [F]

# enable the Proxy module without caching
ProxyRequests on
NoCache *

# setup URL reverse mapping for redirect reponses
ProxyPassReverse / http://www1.foo.dom/
ProxyPassReverse / http://www2.foo.dom/
ProxyPassReverse / http://www3.foo.dom/
ProxyPassReverse / http://www4.foo.dom/
ProxyPassReverse / http://www5.foo.dom/
ProxyPassReverse / http://www6.foo.dom/

##
## apache-rproxy.conf-servers -- Apache/mod_rewrite selection table
##

# list of backend servers which serve static
# pages (HTML files and Images, etc.)
static www1.foo.dom|www2.foo.dom|www3.foo.dom|www4.foo.dom

# list of backend servers which serve dynamically
# generated page (CGI programs or mod_perl scripts)
dynamic www5.foo.dom|www6.foo.dom

新的MIME类型,新的服务
说明:
网上有许多很技巧的CGI程序,但是用法晦涩,许多网管弃之不用。即使是Apache的MEME类型的动作处理器,也仅仅在CGI程序不需要在其输入中包含特殊URL(PATH_INFO和QUERY_STRINGS)时才很好用。首先,配置一种新的后缀为.scgi(for secure CGI)文件类型,其处理器是很常见的cgiwrap程序。问题是:如果使用同类URL规划(见上述),而用户宿主目录中的一个文件的URL是/u/user/foo/bar.scgi,可是cgiwrap要求的URL的格式是/~user/foo/bar.scgi/,以下规则解决了这个问题:

代码:
RewriteRule ^/[uge]/([^/]+)/.www/(.+).scgi(.*) ...
... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3 [NS,T=application/x-http-cgi]

另外,假设需要使用其他程序:wwwlog(显示access.log中的一个URL子树)和wwwidx(对一个URL子树运行Glimpse),则必须对这些程序提供URL区域作为其操作对象。比如,对/u/user/foo/执行swwidx程序的超链是这样的:

代码:
/internal/cgi/user/swwidx?i=/u/user/foo/

其缺点是,必须同时硬编码超链中的区域和CGI的路径,如果重组了这个区域,就需要花费大量时间来修改各个超链。

方案:
方案是用一个特殊的新的URL格式,自动拼装CGI参数:

代码:
RewriteRule ^/([uge])/([^/]+)(/?.*)/* /internal/cgi/user/wwwidx?i=/$1/$2$3/
RewriteRule ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3

现在,这个搜索到/u/user/foo/的超链简化成了:

代码:
HREF="*"

它会被内部地自动转换为

代码:
/internal/cgi/user/wwwidx?i=/u/user/foo/

如此,可以为使用:log的超链,拼装出调用CGI程序的参数。

从静态到动态
说明:
如何无缝转换静态页面foo.html为动态的foo.cgi,而不为浏览器/用户所察觉。

方案:
只须重写此URL为CGI-script,以强制为可以作为CGI-script运行的正确的MIME类型。如此,对/~quux/foo.html的请求其实会执行/~quux/foo.cgi。

代码:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo.html$ foo.cgi [T=application/x-httpd-cgi]

空闲时间内的内容协商
说明:
这是一个很难解的功能:动态生成的静态页面,即,它应该作为静态页面发送(从文件系统中读出,然后直接发出去),但是如果它丢失了,则由服务器动态生成。如此,可以静态地提供CGI生成的页面,除非有人(或者是一个cronjob)删除了这些静态页面,而且其内容可以得到更新。

方案:
以下规则集实现这个功能:
代码:
RewriteCond % !-s
RewriteRule ^page.html$ page.cgi [T=application/x-httpd-cgi,L]
这样,如果page.html不存在或者文件大小为null,则对page.html的请求会导致page.cgi的运行。其中奥妙在于,page.cgi是一个将输出写入page.html的(同时也写入STDOUT)的常规的CGI脚本,执行完毕,服务器则将page.html的内容发出。如果网管需要强制更新其内容,只须删除page.html即可(通常由一个cronjob完成)。

自动更新的文档
说明:
建立一个复杂的页面,能够在用编辑器写了一个更新的版本时自动在浏览器上得到刷新,这不是很好吗?这可能吗?

方案:
这是可行的! 这需要综合利用MIME多成分、网站服务器的NPH和mod_rewrite的URL操控特性。首先,建立一个新的URL特性:对在文件系统中更新时需要刷新的所有URL加上:refresh。

代码:
RewriteRule ^(/[uge]/[^/]+/?.*):refresh /internal/cgi/apache/nph-refresh?f=$1

然后,修改URL

代码:
/u/foo/bar/page.html:refresh

以内部地操控此URL

代码:
/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html

接着就是NPH-CGI脚本部分了。虽然,人们常说"left as an exercise to the reader",我还是给出答案了。

代码:
#!/sw/bin/perl
##
## nph-refresh -- NPH/CGI script for auto refreshing pages
## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##
$| = 1;

# split the QUERY_STRING variable
@pairs = split(/&/, $ENV);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$name =~ tr/A-Z/a-z/;
$name = 'QS_' . $name;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
eval "$$name = "$value"";
}
$QS_s = 1 if ($QS_s eq '');
$QS_n = 3600 if ($QS_n eq '');
if ($QS_f eq '') {
print "HTTP/1.0 200 OKn";
print "Content-type: text/htmlnn";
print "&b&ERROR&/b&: No file givenn";
exit(0);
}
if (! -f $QS_f) {
print "HTTP/1.0 200 OKn";
print "Content-type: text/htmlnn";
print "&b&ERROR&/b&: File $QS_f not foundn";
exit(0);
}

sub print_http_headers_multipart_begin {
print "HTTP/1.0 200 OKn";
$bound = "ThisRandomString12345";
print "Content-type: multipart/x-mixed-replace;boundary=$boundn";
&print_http_headers_multipart_next;
}

sub print_http_headers_multipart_next {
print "n--$boundn";
}

sub print_http_headers_multipart_end {
print "n--$bound--n";
}

sub displayhtml {
local($buffer) = @_;
$len = length($buffer);
print "Content-type: text/htmln";
print "Content-length: $lennn";
print $buffer;
}

sub readfile {
local($file) = @_;
local(*FP, $size, $buffer, $bytes);
($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
$size = sprintf("%d", $size);
open(FP, "&$file");
$bytes = sysread(FP, $buffer, $size);
close(FP);
return $buffer;
}

$buffer = &readfile($QS_f);
&print_http_headers_multipart_begin;
&displayhtml($buffer);

sub mystat {
local($file) = $_[0];
local($time);

($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
return $mtime;
}

$mtimeL = &mystat($QS_f);
$mtime = $mtime;
for ($n = 0; $n & $QS_n; $n++) {
while (1) {
$mtime = &mystat($QS_f);
if ($mtime ne $mtimeL) {
$mtimeL = $mtime;
sleep(2);
$buffer = &readfile($QS_f);
&print_http_headers_multipart_next;
&displayhtml($buffer);
sleep(5);
$mtimeL = &mystat($QS_f);
last;
}
sleep($QS_s);
}
}

&print_http_headers_multipart_end;

exit(0);

##EOF##
大型虚拟主机
说明:
Apache的功能很强,在有几十个虚拟主机的情况下运行得很好,但是如果你是ISP,需要提供几百个虚拟主机,那么这就不是一个最佳的选择了。

方案:
为此,需要用代理吞吐(Proxy Throughput)功能(flag [P])映射远程页面甚至整个远程网络区域到自己的名称空间:

代码:
##
## vhost.map
##
www.vhost1.dom:80 /path/to/docroot/vhost1
www.vhost2.dom:80 /path/to/docroot/vhost2
:
www.vhostN.dom:80 /path/to/docroot/vhostN

代码:
##
## httpd.conf
##
:
# use the canonical hostname on redirects, etc.
UseCanonicalName on

:
# add the virtual host in front of the CLF-format
CustomLog /path/to/access_log "%e %h %l %u %t "%r" %>s %b"
:

# enable the rewriting engine in the main server
RewriteEngine on

# define two maps: one for fixing the URL and one which defines
# the available virtual hosts with their corresponding
# DocumentRoot.
RewriteMap lowercase int:tolower
RewriteMap vhost txt:/path/to/vhost.map

# Now do the actual virtual host mapping
# via a huge and complicated single rule:
#
# 1. make sure we don't map for common locations
RewriteCond % !^/commonurl1/.*
RewriteCond % !^/commonurl2/.*
:
RewriteCond % !^/commonurlN/.*
#
# 2. make sure we have a Host header, because
# currently our approach only supports
# virtual hosting through this header
RewriteCond % !^$
#
# 3. lowercase the hostname
RewriteCond $|NONE} ^(.+)$
#
# 4. lookup this hostname in vhost.map and
# remember it only when it is a path
# (and not "NONE" from above)
RewriteCond $ ^(/.*)$
#
# 5. finally we can map the URL to its docroot location
# and remember the virtual host for logging puposes
RewriteRule ^/(.*)$ %1/$1 [E=VHOST:$}]
:

对访问的限制
阻止Robots
说明:
如何阻止一个完全匿名的robot取得特定网络区域的页面?一个/robots.txt文件可以包含若干"Robot Exclusion Protocol(robot排除协议)"的行,但不足以阻止此类robot。

方案:
可以用一个规则集以拒绝对网络区域/~quux/foo/arc/(对一个很深的目录区域进行列表可能会使服务器产生很大的负载)的访问。还必须确保仅阻止特定的robot,就是说,仅仅阻止robot访问主机是不够的,这样会同时也阻止了用户访问该主机。为此,就需要对HTTP头的User-Agent信息作匹配。

代码:
RewriteCond % ^NameOfBadRobot.*
RewriteCond % ^123.45.67.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
阻止内嵌的图片
说明:
假设,http://www.quux-corp.de/~quux/有一些内嵌图片的页面,这些图片很好,所以就有人用超链连到他们自己的页面中了。由于这样徒然增加了我们的服务器的流量,因此,我们不愿意这种事情发生。

方案:
虽然,我们不能100%地保护这些图片不被写入别人的页面,但至少可以对发出HTTP Referer头的浏览器加以限制。

代码:
RewriteCond % !^$
RewriteCond % !^http://www.quux-corp.de/~quux/.*$ [NC]
RewriteRule .*.gif$ - [F]

RewriteCond % !^$
RewriteCond % !.*/foo-with-gif.html$
RewriteRule ^inlined-in-foo.gif$ - [F]

对主机的拒绝
说明:
如何拒绝一批外部列表中的主机对我们服务器的使用?

方案:
代码:
For Apache >= 1.3b6:

RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteCond $|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond $|NOT-FOUND} !=NOT-FOUND
RewriteRule ^/.* - [F]

For Apache <= 1.3b6:

RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteRule ^/(.*)$ $|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ $|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ /$1

代码:
##
## hosts.deny
##
## ATTENTION! This is a map, not a list, even when we treat it as such.
## mod_rewrite parses it for key/value pairs, so at least a
## dummy value "-" must be present for each entry.
##

193.102.180.41 -
bsdti1.sdm.de -
192.76.162.40 -

对代理的拒绝
说明:
如何拒绝某个主机或者来自特定主机的用户使用Apache代理?

方案:
首先,要确保Apache网站服务器在编译时配置文件中mod_rewrite在mod_proxy的下面(!),使它在mod_proxy之前被调用。然后,如下拒绝某个主机...

代码:
RewriteCond % ^badhost.mydomain.com$
RewriteRule !^http://[^/.].mydomain.com.* - [F]

...如下拒绝user@host-dependent:

代码:
RewriteCond %@% ^badguy@badhost.mydomain.com$
RewriteRule !^http://[^/.].mydomain.com.* - [F]

特殊的认证
说明:
有时候,会需要一种非常特殊的认证,即,对一组明确指定的用户,允许其访问,而没有(在使用mod_access的基本认证方法时可能会出现的)任何提示。

方案:
可是使用一个重写条件列表来排除所有的朋友:

代码:
RewriteCond %@% !^friend1@client1.quux-corp.com$
RewriteCond %@% !^friend2@client2.quux-corp.com$
RewriteCond %@% !^friend3@client3.quux-corp.com$
RewriteRule ^/~quux/only-for-friends/ - [F]

基于提交者(Referer)的反射器
说明:
如何配置一个基于HTTP头"Referer"的反射器以反射到任意数量的提交页面?

方案:
使用这个很技巧的规则集...

代码:
RewriteMap deflector txt:/path/to/deflector.map

RewriteCond % !=""
RewriteCond $} ^-$
RewriteRule ^.* % [R,L]

RewriteCond % !=""
RewriteCond $|NOT-FOUND} !=NOT-FOUND
RewriteRule ^.* $} [R,L]

... 并结合对应的重写地图:

代码:
##
## deflector.map
##

http://www.badguys.com/bad/index.html -
http://www.badguys.com/bad/index2.html -
http://www.badguys.com/bad/index3.html http://somewhere.com/

它可以自动将请求(在地图中指定了"-"值的时候)反射回其提交页面,或者(在地图中URL有第二个参数时)反射到一个特定的URL。

其他
外部重写引擎
说明:
一个常见的问题: 如何解决似乎无法用mod_rewrite解决的FOO/BAR/QUUX/之类的问题?

方案:
可以使用一个与RewriteMap功能相同的外部RewriteMap程序,一旦它在Apache启动时被执行,则从STDIN接收被请求的URL,并将处理过(通常是重写过的)的URL(以相同顺序!)在STDOUT输出。

代码:
RewriteEngine on
RewriteMap quux-map prg:/path/to/map.quux.pl
RewriteRule ^/~quux/(.*)$ /~quux/$

代码:
#!/path/to/perl

# disable buffered I/O which would lead
# to deadloops for the Apache server
$| = 1;

# read URLs one per line from stdin and
# generate substitution URL on stdout
while (<>) {
s|^foo/|bar/|;
print $_;
}

这是一个作演示的例子,只是把所有的URL /~quux/foo/...重写为/~quux/bar/...,而事实上,可以把它修改以获得任何你需要的功能。但是要注意,虽然一般用户都可以使用,可是只有系统管理员才可以定义这样的地图。

March 3, 2006

IIS出现The requested resource is in use的解决办法

有的时候,我们在调用ASP的时候出现了

The requested resource is in use

这个时候在 微软的KB上解决办法是将ASP ISAPI缓存的对号选中
很遗憾,这样不能够解决大部分问题。这个问题依然会困扰着很多人。

The possible cause for this is vbscript.dll reference in registry got messed up and
you need to re-register it.
Try

运行
regsvr32 %windir%/system32/vbscript.dll

问题解决

About 它它它它

This page contains an archive of all entries posted to a one and a two in the 它它它它 category. They are listed from oldest to newest.

学习学习 is the previous category.

幸福生活 is the next category.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.