12.5 基于文件及路径名的攻击（Attacks Based On File and Path Names）
HTTP原始服务器的实现应当注意，要对以服务器管理员名义发出的，对某个文件的HTTP请求进行限制。如果HTTP服务器直接将HTTP URI发送给系统调用，服务器要特别注意，当某个请求文件不是发往HTTP客户端时，要予以拒绝服务。例如，在Unix、Microsoft Windows以及其它的操作系统使用”..”做为上级目录名。在这样的系统下，HTTP服务器端必须禁止通过使用这种结构的请求URI来访问HTTP服务器其它范围的资源。同样，服务器端内部使用的一些文件，包括访问控制文件，配置文件、script代码等，也要受到特别保护，以避免被非法请求获取，导致系统敏感信息暴露。实验证明，哪怕是最小的bug，也可能导致严重的安全问题。
13. 感谢（Acknowledgments）
本文档着重论述补充反馈方式（augmented BNF）及由David H. Crocker在RFC822[7]中定义的一般结构。同样，它使用了许多由Nathaniel Borenstein和Ned Freed为MIME [5]做的许多定义。我们希望通过它们来减少对HTTP/1.0及mail消息格式之间关系的混淆。
HTTP协议在过去四年中发展很快，它得益于庞大而活跃的开发团体――是他们，这些参与WWW讨论邮件列表的人们，造就了HTTP在全球范围内的成功。Marc Andreessen，Robert Cailliau， Daniel W. Connolly，Bob Denny，Jean-Francois Groff， Phillip M. Hallam-Baker， Hakon W. Lie， Ari Luotonen，Rob McCool， Lou Montulli， Dave Raggett，Tony Sanders，和Marc VanHeyningen，他们为本文档早期版本投入了巨大精力。Paul Hoffman提供了关于信息状态方面的信息，以及附录C、D的内容。
Berners-Lee, et al Informational [Page 51]
该文档从HTTP-WG成员的评注中得益非浅。以下是对本规范做出贡献的人们：
Gary Adams Harald Tveit Alvestrand
Keith Ball
Brian Behlendorf
Paul Burchard Maurizio Codogno
Mike Cowlishaw Roman Czyborra
Michael A. Dolan John Franks
Jim Gettys Marc Hedlund
Koen Holtman Alex Hopmann
Bob Jernigan Shel Kaphan
Martijn Koster Dave Kristol
Daniel LaLiberte Paul Leach
Albert Lunde John C. Mallery
Larry Masinter Mitra
Jeffrey Mogul Gavin Nicol
Bill Perry Jeffrey Perry
Owen Rees Luigi Rizzo
David Robinson Marc Salomon
Rich Salz Jim Seidman
Chuck Shotton Eric W. Sink
Simon E. Spero Robert S. Thau
Francois Yergeau Mary Ellen Zurko
Jean-Philippe Martin-Flatin
14. 参考书目（References）
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A
Distributed Document Search and Retrieval Protocol", RFC 1436,
University of Minnesota, March 1993.
[2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web",
RFC 1630, CERN, June 1994.
[3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, MIT/W3C, November 1995.
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
University of Minnesota, December 1994.
Berners-Lee, et al Informational [Page 52]
[5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, Bellcore,
Innosoft, September 1993.
[6]
Braden, R., "Requirements for Internet hosts - Application and
Support", STD 3, RFC 1123, IETF, October 1989.
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
Functional Specification." (v1.5), Thinking Machines
Corporation, April 1990.
[9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
UC Irvine, June 1995.
[10] Horton, M., and R. Adams, "Standard for interchange of USENET
Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell
Laboratories, Center for Seismic Studies, December 1987.
[11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:
A Proposed Standard for the Stream-Based Transmission of News",
RFC 977, UC San Diego, UC Berkeley, February 1986.
[12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,
USC/ISI, August 1982.
[13] Postel, J., "Media Type Registration Procedure." RFC 1590,
USC/ISI, March 1994.
[14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/ISI, October 1985.
[15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/ISI, October 1994.
[16] Sollins, K., and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
December 1994.
[17] US-ASCII. Coded Character Set - 7-Bit American Standard Code
for Information Interchange. Standard ANSI X3.4-1986, ANSI,
1986.
Berners-Lee, et al Informational [Page 53]
[18] ISO-8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
15. 作者地址（Authors' Addresses）
Tim Berners-Lee
Director, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Roy T. Fielding
Department of Information and Computer Science
University of California
Irvine, CA 92717-3425, U.S.A.
Fax: +1 (714) 824-4056
EMail: fielding@ics.uci.edu
Henrik Frystyk Nielsen
W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Berners-Lee, et al Informational [Page 54]
附录（Appendices）
这些信息出现在附录中仅有一个理由，即他们没有成为HTTP/1.0规范的组成部分。
A. Internet介质类型消息/http（Internet Media Type message/http）
做为HTTP/1.0协议的补充，该文档做为Internet介质类型”message/http”的规范。下面内容被登记在IANA[13]中。
介质类型名（Media Type name）： message
介质子类型名（Media subtype name）： http
请求参数（Required parameters）： none
可选参数项（Optional parameters）： version, msgtype
版本（version）：附加消息的HTTP版本号，比如“1.0”。如果没有给出，版本可以从其主体的第一行中得到。
消息类型（msgtype）：消息类型――请求（request）或回应（response）。如果没有给出，版本可以从其主体的第一行中得到。
编码考虑（Encoding considerations）：只允许用"7bit", "8bit",或"binary" 。
安全考虑（Security considerations）： none
B. 容错应用（Tolerant Applications）
虽然此文档指明了产生HTTP/1.0消息的必要条件，并非所有的应用程序都校正他们的实现。因此，我们建议应用程序增强其容错能力，以便在岐义仍可被明确解释时，还能保证正常运行。
客户端解析状态行（Status-Line）及服务器解析请求行（Request-Line）时，应当做到容错。特别是，即使只需要一个SP分隔的情况下，它们也可接受以任何数量的SP或HT字符分隔的域。
HTTP标题域的行终止符是顺序字符CRLF。而我们建议应用程序在解析这类标题时，也应识别单个LF（没有前面的CR）做为终止符情况。
Berners-Lee, et al Informational [Page 55]
C. 与MIME的关系（Relationship to MIME）
HTTP/1.0使用了许多为Internet Mail（RFC822[7]）及多用途Internet邮件扩展（Multipurpose Internet Mail Extensions）MIME[5]定义的结构，以允许实体通过一种开放的可扩展的机制进行传输。实际上，HTTP中有些特性与RFC1521中讨论的邮件不同，这些区别被用来优化二进制传输的性能，给介质类型的使用提供了更大的自由度，使日期比较变得更加容易，当然，这也是为了兼容早期的一些HTTP服务器及客户端的应用。
在写作本文时，据说RFC1521将被修订。修订版本将会包括一些出现在HTTP/1.0中的已有的应用，但这些应用在目前的RFC1521中尚未包括。
该附录描述了HTTP与RFC1521中的不同之处。代理和网关在限制MIME环境时，应当注意到这些区别，并在必须时提供相应的转换支持。从MIME到HTTP环境的代理和网关也要注意这些区别，因为一些转换可能是必须的。
C.1 转换为规范形式（Conversion to Canonical Form）
RFC1521要求Internet邮件实体在被传输前转换成规范形式，正如RFC1521[5]附录C中所描述的那样。本文档中3.6.1节中描述了HTTP在传输时允许的“text”介质类型的子类型的具体形式。
RFC1521要求”text”的内容类型（Content-Type）必须用CRLF作为行中断符，禁止单独使用CR或LF。HTTP允许在HTTP传输时使用CRLF、单独的CR或LF做为行中断符。
只要有可能，HTTP环境或RFC1521环境下的代理或网关应当将本文档3.6.1节中描述的文本介质类型中的所有行中断符都转换成CRLF。注意，由于存在着内容编码（Content-Encoding）问题，以及HTTP允许使用多字符集，而其中的某些字符集不用字节13和10做为CR和LF，这样就使实际的处理更加复杂。
Berners-Lee, et al Informational [Page 56]
C.2 日期格式转换（Conversion of Date Formats）
HTTP/1.0使用受限制的日期格式集（3.3节）以简化日期比较的处理。其它协议的代理和网关应当保证消息中的任何日期标题域与HTTP/1.0格式一致，否则，要对其进行改写。
C.3 内容编码介绍（Introduction of Content-Encoding）
RFC1521不包括殊如HTTP/1.0中内容编码标题域之类的概念。由于内容类型域是介质类型的修饰，因而从HTTP到MIME兼容协议中的代理和网关必须在将消息向前推送之前，更改内容类型标题域（Content-Type）的值或者对实体主体（Entity-Body）进行解码（有些Internet mail内容类型的实验性应用采用介质类型参数为";conversions=<content-coding>"来替代内容解码，而事实上，该参数并非RFC1521的组成部分）。
C.4 无内容传输编码（No Content-Transfer-Encoding）
HTTP不使用RFC1521的CTE（Content-Transfer-Encoding）域。与MIME协议兼容的代理和网关在向HTTP客户端传递回应消息前都必须清除任何无标识的CTE编码（"quoted-printable"或"base64"）。
从HTTP到MIME兼容协议的代理和网关要负责保证协议上消息格式正确及编码传输安全，所谓安全传输是指满足对应协议所规定的限制或约束标准。代理或网关应当用适当的内容传输编码（Content-Transfer-Encoding）来标识数据，以提高在目的协议上实现安全传输的可能性。
C.5 多个主体的HTTP标题域（HTTP Header Fields in Multipart Body-Parts）
在RFC1521中，大多数多个主体组成的标题域通常会被忽略，除非其域名以”Content-“开头。在HTTP/1.0中，多个主体部分（multipart body-parts）所包含的任何HTTP标题域，只对对应的部分有意义。
D. 附加特性（Additional Features）
该附录中包括的一些协议元素存在于一些HTTP实现中，但并非对所有的HTTP/1.0的应用都适用。开发者应注意这些特性，但不能依赖它们来与其它的HTTP/1.0应用程序进行交互。
Berners-Lee, et al Informational [Page 57]
D.1 附加请求方法（Additional Request Methods）
D.1.1 PUT
PUT方法请求服务器将附件的实体储存在提供的请求URI处。如果该请求URI指向的资源已经存在，则附件实体应被看做是当前原始服务器上资源的修改版本。如果请求URI没有指向现存的资源，该URI将被该请求的用户代理定义成为一个新的资源，原始服务器将用该URI产生这个资源。
POST与PUT两种请求的基本区别在于对请求URI的理解不同。在POST请求方法中的URI所标识的资源将做为附件实体被服务器处理，该资源可能是数据接收处理过程、某些其它协议的网关、或可被注释的单独实体。与此相反，用户代理很清楚它发出的PUT请求中附带URI所标识的实体指向何处，而服务器处不应将该请求用到其它资源头上。
D.1.2 DELETE
DELETE方法请求原始服务器删除由请求URI所指定的资源。
D.1.3 LINK
LINK方法建立与请求URI所指定资源或其它已存在资源之间的一个或多个连接关系。
D.1.4 UNLINK
UNLINK方法删除与请求URI所指定资源之间的一个或多个连接关系。
D.2 附加标题域定义（Additional Header Field Definitions）
D.2.1 Accept
Accept请求标题域用于指示可被接受的请求回应的介质范围列表。星号”*”用于按范围将介质类型分组，用”*/*”指示可接受全部介质类型；用”type/*”指示可接受type类型的所有子类型。对于给定请求的上下文，客户端应当表示出哪些类型是它可以接受的。
Berners-Lee, et al Informational [Page 58]
D.2.2 可接受的字体集（Accept-Charset）
Accept-Charset请求标题域用来指示除了US-ASCII和ISO-8859-1外，首选的字符集。该域将使客户端有能力理解更广泛的或有特殊用途的字符集，从而在服务器上可以存放采用此类字符集的文档。
D.2.3 可接受编码（Accept-Encoding）
Accept-Encoding请求标题域与Accept相似，但是限制了回应中可接受的内容编码（content-coding）值。
D.2.4 可接受语言（Accept-Language）
Accept-Language请求标题域与Accept相似，但限制了请求回应中首选的自然语言集。
D.2.5 内容语言（Content-Language）
Content-Language实体标题域描述了附加实体中为听众指定的自然语言。注意，这可能与在实体内部使用的各种语言不是一码事。
D.2.6 连接（Link）
Link实体标题域描述了实体和某些其它资源之间的关系。一个实体可能包括多个连接值。处于元信息级的Link指明了分层结构和导航路径之间的关系。
D.2.7 MIME版本（MIME-Version）
HTTP消息可能包括一个单独的MIME版本的普通标题（general-header）域，用以指示用来构造消息的MIME协议的版本。MIME版本标题域的使用，正如RFC1521[5]中定义的那样，应当用来指示消息是否符合MIME规范。然而不幸的是，一些老的HTTP/1.0服务器不加选择地发送此域，导致此域已经被废弃。
Berners-Lee, et al Informational [Page 59]
D.2.8 在….后重试（Retry-After）
Retry-After回应标题域可与503（服务不可用）回应一起使用，用于指示服务器停止响应客户请求的时间长短。该域的值可用HTTP格式的日期表示，也可以用整数来表示回应时间后的秒数。
D.2.9 标题（Title）
Title实体标题域用于指示实体的标题。
D.2.10 URI
URI实体标题域可能包含一些或全部统一资源标识（Uniform Resource Identifiers），见3.2节，通过这些标识来表示请求URI所指定的资源。并不担保根据URI一定能够找到指定的资源。
Berners-Lee, et al Informational [Page 60]
译者声明：
本文档由chifire（chifire@263.net）翻译。
本文档在排版格式上尽可能保持与原RFC文档的一致。
由于本人水平有限，可能有些地方译得不够准确，甚至错误，或某些术语翻译有误，还请各位大侠见谅，并来信批评指正。
