PHPor 的Blog

下面是一个常见的获取用户ip的函数：

<?php
function getip()
{
    if(getenv("HTTP_CLIENT_IP") && getenv("HTTP_CLIENT_IP")!="unknown")
        $ip = getenv("HTTP_CLIENT_IP");
    elseif(getenv("HTTP_X_FORWARDED_FOR") && getenv("HTTP_X_FORWARDED_FOR")!="unknown")
        $ip = getenv("HTTP_X_FORWARDED_FOR");
    elseif(getenv("REMOTE_ADDR") && getenv("REMOTE_ADDR")!="unknown")
        $ip = getenv("REMOTE_ADDR");
    else    
        $ip = "none"; 

    return $ip;
}
?>

下面给出一个测试脚本：

<?php
$ch = curl_init();
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_HTTP_VERSION,CURL_HTTP_VERSION_1_1);
curl_setopt($ch,CURLOPT_HTTPHEADER,array(‘X_FORWARDED_FOR: 158.10.10.10’));
curl_setopt($ch,CURLOPT_HTTPHEADER,array(‘CLIENT_IP: 159.10.10.10’));
curl_setopt($ch, CURLOPT_URL,"http://10.10.10.21/test.php");
echo curl_exec($ch);
curl_close($ch);
exit;
?>

References

http1.0: RFC 1945.

http1.1: RFC 2068

 

Status Code

The Warning header

HTTP status codes indicate the success or failure of a request. For a successful response, the status code cannot provide additional advisory information, in part because the placement of the status code in the Status-Line, instead of in a header field, prevents the use of multiple status codes.

HTTP/1.1 introduces a Warning header, which may carry any number of subsidiary status indications. The intent is to allow a sender to advise the recipient that something may be unsatisfactory about an ostensibly successful response.

HTTP/1.1 defines an initial set of Warning codes, mostly related to the actions of caches along the response path. For example, a Warning can mark a response as having been returned by a cache during disconnected operation, when it is not possible to validate the cache entry with the origin server.

The Warning codes are divided into two classes, based on the first digit of the 3-digit code. One class of warnings must be deleted after a successful revalidation of a cache entry; the other class must be retained with a revalidated cache entry. Because this distinction is made based on the first digit of the code, rather than through an exhaustive listing of the codes, it is extensible to Warning codes defined in the future.

Other new status codes

There are 24 new status codes in HTTP/1.1; we have discussed 100 (Continue), 206 (Partial Content), and 300 (Multiple Choices) elsewhere in this paper. A few of the more notable additions include

* 409 (Conflict), returned when a request would conflict with the current state of the resource. For example, a PUT request might violate a versioning policy.

* 410 (Gone), used when a resource has been removed permanently from a server, and to aid in the deletion of any links to the resource.

Most of the other new status codes are minor extensions.

HTTP1.0

HTTP1.1

HTTP/1.0 does not define any 1xx status

codes and they are not a valid response to a HTTP/1.0 request.

100 Continue

101 Switching Protocols

Undifined

203 Non-Authoritative Information

Undifined

205 Reset Content

Undifined

206 Partial Content

Undifined

303 See Other

Undifined

305 Use Proxy

Undifined

402 Payment Required

Undifined

405 Method Not Allowed

Undifined

406 Not Acceptable

Undifined

407 Proxy Authentication Required

Undifined

408 Request Timeout

Undifined

409 Conflict

Undifined

410 Gone

Undifined

411 Length Required

Undifined

412 Precondition Failed

Undifined

413 Request Entity Too Large

Undifined

414 Request-URI Too Long

Undifined

415 Unsupported Media Type

Undifined

504 Gateway Timeout

Undifined

505 HTTP Version Not Supported

HTTP/1.0 -> HTTP/1.1

Changes to Simplify Multi-homed Web Servers and Conserve IP

Addresses

The requirements that clients and servers support the Host request-

header, report an error if the Host request-header (section 14.23) is

missing from an HTTP/1.1 request, and accept absolute URIs (section

5.1.2) are among the most important changes defined by this

specification.

Older HTTP/1.0 clients assumed a one-to-one relationship of IP

addresses and servers; there was no other established mechanism for

distinguishing the intended server of a request than the IP address

to which that request was directed. The changes outlined above will

allow the Internet, once older HTTP clients are no longer common, to

support multiple Web sites from a single IP address, greatly

simplifying large operational Web servers, where allocation of many

IP addresses to a single host has created serious problems. The

Internet will also be able to recover the IP addresses that have been

allocated for the sole purpose of allowing special-purpose domain

names to be used in root-level HTTP URLs. Given the rate of growth of

the Web, and the number of servers already deployed, it is extremely

important that all implementations of HTTP (including updates to

existing HTTP/1.0 applications) correctly implement these

requirements:

o Both clients and servers MUST support the Host request-header.

o Host request-headers are required in HTTP/1.1 requests.

o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1

request does not include a Host request-header.

o Servers MUST accept absolute URIs.

Persistent

HTTP/1.0

experimental implementations of persistent connections are faulty,

and the new facilities in HTTP/1.1 are designed to rectify these

problems. The problem was that some existing 1.0 clients may be

sending Keep-Alive to a proxy server that doesn’t understand

Connection, which would then erroneously forward it to the next

inbound server, which would establish the Keep-Alive connection and

result in a hung HTTP/1.0 proxy waiting for the close on the

response. The result is that HTTP/1.0 clients must be prevented from

using Keep-Alive when talking to proxies.

original HTTP/1.0 form of persistent

connections.

When it connects to an origin server, an HTTP client MAY send the

Keep-Alive connection-token in addition to the Persist connection-

token:

Connection: Keep-Alive

An HTTP/1.0 server would then respond with the Keep-Alive connection

token and the client may proceed with an HTTP/1.0 (or Keep-Alive)

persistent connection.

An HTTP/1.1 server may also establish persistent connections with

HTTP/1.0 clients upon receipt of a Keep-Alive connection token.

However, a persistent connection with an HTTP/1.0 client cannot make

use of the chunked transfer-coding, and therefore MUST use a

Content-Length for marking the ending boundary of each message.

A client MUST NOT send the Keep-Alive connection token to a proxy

server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1

for parsing the Connection header field.

In HTTP/1.0, most implementations used a new connection for each

request/response exchange. In HTTP/1.1, a connection may be used for

one or more request/response exchanges, although connections may be

closed for a variety of reasons .

Content Negotiation

  Web users speak many languages and use many character sets. Some Web resources are available in several variants to satisfy this multiplicity. HTTP/1.0 included the notion of content negotiation, a mechanism by which a client can inform the server which language(s) and/or character set(s) are acceptable to the user.

Content negotiation has proved to be a contentious and confusing area. Some aspects that appeared simple at first turned out to be quite difficult to resolve. For example, although current IETF practice is to insist on explicit character set labeling in all relevant contexts, the existing HTTP practice has been to use a default character set in most contexts, but not all implementations chose the same default. The use of unlabeled defaults greatly complicates the problem of internationalizing the Web.

HTTP/1.0 provided a few features to support content negotiation, but RFC1945 never uses that term and devotes less than a page to the relevant protocol features. The HTTP/1.1 specification specifies these features with far greater care, and introduces a number of new concepts.

The goal of the content negotiation mechanism is to choose the best available representation of a resource. HTTP/1.1 provides two orthogonal forms of content negotiation, differing in where the choice is made:

1.

In server-driven negotiation, the more mature form, the client sends hints about the user’s preferences to the server, using headers such as Accept-Language, Accept-Charset, etc. The server then chooses the representation that best matches the preferences expressed in these headers.

2.

In agent-driven negotiation, when the client requests a varying resource, the server replies with a 300 (Multiple Choices) response that contains a list of the available representations and a description of each representation’s properties (such as its language and character set). The client (agent) then chooses one representation, either automatically or with user intervention, and resubmits the request, specifying the chosen variant.

Although the HTTP/1.1 specification reserves the Alternates header name for use in agent-driven negotiation, the HTTP working group never completed a specification of this header, and server-driven negotiation remains the only usable form.

Some users may speak multiple languages, but with varying degrees of fluency. Similarly, a Web resource might be available in its original language, and in several translations of varying faithfulness. HTTP introduces the use of quality values to express the importance or degree of acceptability of various negotiable parameters. A quality value (or qvalue) is a fixed-point number between 0.0 and 1.0. For example, a native speaker of English with some fluency in French, and who can impose on a Danish-speaking office-mate, might configure a browser to generate requests including

Accept-Language: en, fr;q=0.5, da;q=0.1

Because the content-negotiation mechanism allows qvalues and wildcards, and expresses variation across many dimensions (language, character-set, content-type, and content-encoding) the automated choice of the best available” variant can be complex and might generate unexpected outcomes. These choices can interact with caching in subtle ways.

Content negotiation promises to be a fertile area for additional protocol evolution. For example, the HTTP working group recognized the utility of automatic negotiation regarding client implementation features, such as screen size, resolution, and color depth. The IETF has created the Content Negotiation working group to carry forward with work in the area.

Other

A server MUST NOT send

transfer-codings to an HTTP/1.0 client.

19 附录
19.1 互联网媒体类型message/http和application/http
这篇文档除了定义HTTP/1.1协议外，还用作互联网媒介类型"message/http"和"application/http"的规范。此类型用于封装一个HTTP请求消息或响应消息，这假设此类型遵循MIME对 所有“消息”类型关于行长度和编的限制。application/http类型可以用来封装一个或者更多HTTP请求或响应信息（非混合的）的传输路径（pipeline）。下列是在IANA[17]注册的。

        媒介类型名称：    message

        媒介次类型名称： http

        必须参数：        无

        可选参数：        版本，信息类型

        版本：封装信息的HTTP版本号（例如，"1.1"）。如果不存在，版本可以从消息的第一行确定。

        信息类型：信息类型–"请求"或者"响应"。如果不存在，类型可以从报文的第一行确定。  

        编码考虑：只有"7bit"，"8bit"，或者"二进制"是允许的。

        安全考虑：无

        媒介类型名称：    application

        媒介次类型名称： http

        必须参数：        无

        可选参数：        版本，信息类型

        版本：封装信息的HTTP版本号（例如，"1.1"）。如果不存在，版本可以从报文的第一行确定。

        信息类型：信息类型–"request"或者"response"。如果不存在，类型可以从报文的第一行确定。      

        编码考虑：用这种类型封装的HTTP信息是"二进制"的格式；当通过E-mail传递的时候一种合适的内容传输编码是必须的。

        安全考虑：无          

19.2 互联网媒体类型multipart/byteranges
当一个HTTP206（部分内容）响应信息包含多个范围的内容（请求响应的内容有多个非重叠的范围），这些是作为一个多部分消息主体来被传送的。这种用途的媒体类型被称作"multipart/byteranges"。

multipart/byteranges媒体类型包括两个或者更多的部分，每一个都有自己Content-type和Content-Range头域。必需的分界参数（boundary parameter）指定分界字符串，此分界字符串用来隔离每一部分。

        媒介类型名称：    multipart

        媒介次类型名称： byteranges

        必须参数：        boundary

        可选参数：        无

        编码考虑：只有"7bit"，"8bit"，或者"二进制"是允许的。

        安全考虑：无          

例如：

HTTP/1.1 206 Partial Content

   Date: Wed, 15 Nov 1995 06:25:24 GMT

   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

   Content-type:multipart/byteranges;boundary=THIS_STRING_SEPARATES

   –THIS_STRING_SEPARATES

   Content-type: application/pdf

   Content-range: bytes 500-999/8000

   …第一部分…

   –THIS_STRING_SEPARATES

   Content-type: application/pdf

   Content-range: bytes 7000-7999/8000

   …第二部分

   –THIS_STRING_SEPARATES–

注意：

在实体（entity）中，在第一个分界字符串之前可以有多余的CRLFs。

虽然RFC 2046 [40]允许分界字符串加引号，但是一些现有的实现会不正确的处理分界字符串

许多浏览器和服务器是按照字节范围标准的早期草案关于使用multipart/x-byteranges媒体类型来进行编码的的，这个草案不总是完全和HTTP/1.1中描述的版本兼容。

19.3 宽松的应用程序 （Tolerent Applications）
虽然这篇文档列出了HTTP/1.1消息所必须的元素，但是并不是所有的程序在实现的时候都是正确的。因此我们建议当偏差可以明确解释的时候，运算程序对这种偏差应该是宽容的。

客户端应该宽松的解析Status-Line（状态行）；服务器也应该宽松的解析Request-Line（请求行）。特别的，他们应该可以接受头域之间任何数量的SP或HT字符，即使协议规定只有一个SP。

消息头域的行终结符是CRLF。然而，当解析这样的头域时，我们建议应用程序能识别单一LF作为行终结符并能忽略CR。

实体主体（entity-body）的字符集应该被标记为应用于实体主体字符编码的最小公分母，并且期望不对实体进行标记要优于对实体标记为US-ASCII或ISO-8859-1。见3.7.1和3.4.1。

对关于日期分析和编码的要求的额外规则以及其它对日期编码的潜在问题包含：

Ø         HTTP/1.1客户端和缓存应该假定一个似乎是50多年以后的RFC-850日期实际上是过去的（这有助于解决"2000年"问题）。

Ø         一个HTTP/1.1的实现可以内部地表示一个比正确日期值更早的已解析后的Expires日期，但是一定不要（MUST NOT）内部地表示一个比正确日期值更迟的已解析过的Expires日期。

Ø         所有过期日期相关的计算必须用GMT时间。本地时区一定不能（MUST NOT）影响年龄或过期时间的计算。

Ø         如果一个HTTP头域不正确的携带了一个非GMT时间区的日期值，那么必须利用最保守的可能转换把此日期值转换成GMT时间值。

19.4 HTTP实体和RFC 2045实体之间的区别
HTTP/1.1使用了许多Internet Mail（RFC 822 [9]）和Multipurpose Internet Mail Extensions（MIME [7]）里定义的结构，去允许实体以多种表现形式和扩展机制去传输。然而，RFC2045讨论邮件，并且HTTP有许多不同于RFC2045里描述的特征。这些不同被小心地挑选出来优化二进制连接的性能，为了允许使用新的媒体类型有更大的灵活性，为了使时间比较变得容易，和为了承认一些早期HTTP服务器和客户端的实效。

本附录描述了HTTP协议不同于RFC 2045的特殊区域。在严格的MIME环境中的代理和网关应该意识到这些不同并且在必要的时候要提供合适地转换。从MIME环境到HTTP的代理服务器和网关也需要意识到这些不同因为一些转换可能是需要的。

19.4.1 MIME版本（MIME-Version）
HTTP不是一个遵守MIME的协议。然而HTTP/1.1消息可以（MAY）包含一个单独的MIME-Version常用头域用来指出什么样的MIME协议版本被用于去构造消息。利用MIME-Version头域指明完全遵循MIME协议的消息（在RFC2045[7]）。代理/网关要保证完全遵守MIME协议当把HTTP消息输出到严格MIME环境的时候。

    MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

在HTTP/1.1用的缺省值是MIME1.0版本。然而，HTTP/1.1消息的解析和语义是由本文档而不是MIME规范定义的。

19.4.2转换到规范化形式 （Conversion to Canoical Form）
RFC 2045 [7]需要一个Internet mail实体在被传输之前要被转换成一个规范化的形式，这在RFC2049[48]里第四章里描述的。这篇文档的3.7.1节描述了当用HTTP协议传输时允许使用的”text”子媒体类型的形式。RFC2046要求以类型为“text”的内容要用CRLF表示为换行符，以及在换行符外禁止使用CR或LF。

RFC 2046需要像在"text"类型的内容里一样，用CRLF表示行间隔符并禁止在行间隔符序列以外使用CR或者LF。HTTP允许CRLF，单个CR，和单个LF来表示一个换行符在一个文本内容消息中。

在可能的地方，从HTTP到严格MIME环境的代理或网关应该（SHOULD）把RFC2049里描述的text媒体类型里所有换行符转换成RFC2049里CRLF的规范形式。然而，注意这可能在Content-Encoding出现的时候，以及HTTP允许利用一些没有利用13和10代表CR和LF的字符集时候都会变得复杂。

实现者应该注意转换将会破坏任何应用于源内容（original content）的密码校验和，除非源内容已经是规范化形式。因此，对任何在HTTP中使用校验和的内容被建议要表示为规范化形式。

19.4.3日期格式的转换 （Conversion of Date Formate）
为了简化日期比较的过程，HTTP/1.1使用了一个限制的日期格式（3.3.1节）。其它协议的代理和网关应该保证任何消息里出现的Date头域应该遵循HTTP/1.1规定的格式，如果有必要需要重写此日期。

19.4.4 Content-Encoding头域介绍 （Introduction of Content-Encoding）
RFC 2045不包含任何等价于HTTP/1.1里Content-Encoding头域的概念。因为这个头域作为媒体类型（media type）的修饰，从HTTP协议到MIME遵守的协议的代理和网关在转发消息之前必须既能改变Content-Type头域的值，也能解码实体主体（entity-body）.。（一些为Internet mail类型的Content-Type的实验性的应用已经使用了一个媒体类型参数“; conversions=<content-coding>”去执行等价于Content-Encoding的功能。然而，此参数并不是RFC2045的部分）

19.4.5没有Content-Transfer-Encoding头域
HTTP不使用RFC 2045里的Content-Transfer-Encoding（CTE）头域。从使用MIME协议到HTTP的代理和网关在把响应消息发送给HTTP客户端之前必须删除任何非等价（non-identity，译注：identity编码，表示没有进行任何编码）CTE（"quoted-printable"或"base64"）编码。

从HTTP到MIME协议遵循的代理和网关要确保消息在那个协议安全传输上是用正确的格式和正确的编码，“安全传输”是通过使用的协议的限制而被定义的。这样一个代理或网关应该用合适的Content-Transfer-Encoding头域来标记数据如果这样做将提高安全传输的可能性。

19.4.6 Transfer-Encoding头域的介绍
HTTP/1.1介绍了Transfer-Encoding头域（14.41节）。代理/网关在转发经由MIME协议的消息之前必须移除任何传输编码。

一个解码"chunked"传输代码（3.6节）的程序可以用代码表示如下：

       length := 0

       read chunk-size, chunk-extension （if any） and CRLF

       while （chunk-size > 0） {

          read chunk-data and CRLF

          append chunk-data to entity-body

          length := length + chunk-size

          read chunk-size and CRLF

       }

       read entity-header

       while （entity-header not empty） {

          append entity-header to existing header fields

          read entity-header

       }

       Content-Length := length

       Remove "chunked" from Transfer-Encoding

19.4.7 MHTML和行长度限制
和MHTML实现共享代码的HTTP实现需要了解MIME行长度限制。因为HTTP没有这个限制，HTTP并不折叠长行。用HTTP传输的MHTML消息遵守所有MHTML的规定，包括行长度的限制和折叠，规范化等，因为HTTP传输所有消息主体（见3.7.2）并且不解析消息的内容和消息中包含任何MIME头域。

19.5 其它特征
RFC 1945和RFC 2068里一些协议元素被一些已经存在的HTTP实现使用，但是这些协议元素对于大多数HTTP/1.1应用程序既不兼容也不正确。实现者被建议去了解这些特征，但是不能依赖于它们的出现或不依赖于与其它HTTP/1.1应用程序的互操作性。这些特征中的一些特征描述了实验性的特征，以及还有一些特征描述了没有在基本HTTP/1.1规范里被描述的实验性部署特征。

一些其它头域，如Content-Dispositon和Title头域，他们来自于SMTP和MIME协议，他们同样经常被实现（见2076[37]）.

19.5.1 Content-Disposition
Content-Disposition响应头域被建议作为一个这样的用途，那就是如果用户请求要使内容被保存为一个文件，那么此头域被源服务器使用去建议的一个缺省的文件名。此用途来自于RFC1806[35]关于对Content-Disposition的定义。

        content-disposition = "Content-Disposition" ":"

                              disposition-type *（ ";" disposition-parm ）

        disposition-type = "attachment" | disp-extension-token

        disposition-parm = filename-parm | disp-extension-parm

        filename-parm = "filename" "=" quoted-string

        disp-extension-token = token

        disp-extension-parm = token "=" （ token | quoted-string ）

一个例子是：

      Content-Disposition: attachment; filename="fname.ext"

接收用户的代理不应该（SHOULD NOT）关注任何在filename-parm参数中出现的文件路径信息，这个参数被认为在这次仅仅是应用于HTTP实现。文件名应该（SHOULD）只被当作一个终端组件。

如果此头域用于一个Content-Type为application/octet-stream响应里，那么含义就是用户代理不应该展现响应，但是它应该直接进入一个‘保存响应为…’对话框。

见15.5节关于Content-Disposition的的安全问题。

19.6 和以前版本的兼容
要求和以前的版本的兼容超出了协议规范的范围。然而HTTP/1.1有意设计成很容易支持以前的版本。必须值得注意的是，在写这份规范的时候，我们希望商业的HTTP/1.1服务器去：

      –接受HTTP/0.9，1.0和1.1请求的请求行（Request-Line）格式；

      –理解HTTP/0.9，1.0或1.1格式中的任何有效请求；

      –恰当地用客户端使用的主要版本来响应。

并且我们希望HTTP/1.1的客户端：

      –接受HTTP/1.0和1.1响应的状态行（Status-Line）格式；

      –懂得HTTP/0.9，1.0或1.1的格式的任何有效的响应。

对大多数HTTP/1.0的实现，每一个连接要在请求之前被客户端建立，并且在发送响应之后要被服务器关闭。一些实现了在RFC 2068 [33]的19.7.1节描述的持久连接的Keep-Alive版本。

19.6.1对HTTP/1.0的改变
这一部分总结HTTP/1.0和HTTP/1.1之间主要的区别。

19.6.1.1 对多主机web服务器和保留IP地址简化的改变
客户端和服务器必须支持Host请求头域，并且如果Host请求头域在HTTP/1.1请求里缺少，那么服务器应该报告一个错误，并且服务器能接受一个绝对URIs（5.1.2节），对于这个要求是在此规范里最重要的改变。上面的改变将允许互联网，一旦旧的客户端不再常用时，去支持一个IP地址的多个web站点，这大大简化了大型运算的web服务器，在那里分配多个IP地址给一个主机（host）会产生很严重的问题。此互联网照样能恢复这样一个IP地址，此IP地址作为特殊目的被分配给被用于根级HTTPURLs的域名。给定web的增长速度，服务器的部署数量部，那么所有HTTP实现（包括对已存HTTP/1.0应用程序）应该正确地满足下面这些需求：

    –客户端和服务器都必须（MUST）支持Host请求头域。

    –发送HTTP/1.1请求的客户端必须（MUST）发送Host头域。

    –如果HTTP/1.1请求不包括Host请求头域，服务器就必须（MUST）报告错误400（Bad Request）。

    –服务器必须（MUST）接受绝对URIs（absolute URIs）。

19.6.2和HTTP/1.0持续连接的兼容
一些客户端和服务器可能希望和一些对以前持续连接实现的HTTP/1.0客户端和服务器兼容。HTTP/1.0持久连接需要显示地协商，因为它们不是缺省的行为。持久连接的HTTP/1.0实验性的实现有错误，并且HTTP/1.1里的新的功能被设计成去矫正这些问题。此问题是一些已经存在的1.0客户端可能会发送Keep-Alive头域给不理解连接的代理服务器，然后代理服务器会把此Keep-Alive转发给下一个入流（inbound）服务器。所以HTTP/1.0客户端必须禁止利用Keep-Alive当和代理会话的时候。

然而，和代理进行会话最重要是利用持久连接，所以那个禁止很显然不能被接受。因此，我们需要一些其它的机制去指明需要一个持久连接，并且它必须能安全的使用甚至当和忽略连接的老代理。持久连接缺省是为HTTP/1.1消息的；为了声明非持久连接（见14.10节），我们介绍一个新的关键字（Connection：close）。

持久连接的源HTTP/1.0的形式（the Connection: Keep-Alive and Keep-Alive 头域）在RFC2068里说明

19.6.3对RFC 2068的改变
这篇规范已经被仔细的审查来纠正关键字的用法和消除它们的歧义；RFC 2068在遵守RFC 2119 [34] 制定的协定方面有很多问题。

澄清哪个错误代码将会使入流服务器失灵（例如DNS失灵）。（10.5.5节）

Create有一个特点当一个资源第一次被创建的时候必须需要一个Etag。（10.2.2节）

Content-Base头域从此规范里删除了：它无法广泛的实现，并且在没有健壮的扩展机制的情况下，没有简单的，安全的方式去介绍它。并且，它以一种相似的而不是相同的方式在MHTML[45]里被使用。