11. 访问鉴别（Access Authentication）
HTTP提供了一个简单的质询回应（challenge-response）鉴别机制，可用于服务器通过
客户端提供的授权信息来对其进行身份鉴别。授权方案用可扩展的、大小写敏感的符号来标
识，后跟获取证明所需要的以逗号分隔的‘属性－值’对。
auth-scheme = token
auth-param = token "=" quoted-string
原始服务器用401（未授权）回应消息来质询用户代理的授权。该回应必须包括WWW-
授权标题域，而该WWW-授权标题域包括一个以上用于请求资源认证的参数（challenge）。
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
凡涉及到参数（challenge）处理的授权方案都有realm属性（大小写敏感）。与标准URL
（相对于被访问服务器root）联合使用的realm值（也是大小写敏感）用来定义保护区域。
Realm使得服务器上的被保护资源被放在特殊的保护分区内，这些区域都有各自的授权方案
和（或）授权数据库。Relm值是个字符串，通常由原始服务器来分配，对于授权方案来说，
可能存在些附加的语法处理问题。
通常，用户代理在收到401（未授权）回应时，可能（也可能不会）希望服务器对其授
权。如果希望授权，用户代理将在请求中加入授权请求标题（Authorization request-header）
域。授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息。
credentials = basic-credentials
| ( auth-scheme #auth-param )
可由用户代理通过信任方式来访问的区域由保护区域决定。如果早先的请求已经通过认
证，在由授权方案，参数和（或）用户选择等所指定的时间间隔内，其它的请求可通过相同
的信任来访问该保护区域。
除非由授权另行指定，否则单个保护区域的范围不能扩展到服务器之外。
如果服务器不希望通过请求来接受信任，它应当返回403（禁止）回应。
HTTP协议的访问授权不限于这种简单的质询回应（challenge-response）机制，还可以
使用其它的方法，比如传输级加密或消息封装及通过附加标题域来指定授权信息等等。但是，
这些方法不在本文档的讨论范围。
代理必须完全透明地处理用户授权，也就是说，它们必须在不做任何改动的前提下将
WWW-授权及授权标题向前推送，也不可以对包含授权的回应进行缓存。HTTP/1.0不为客
户端提供通过代理方式授权的方法。
11.1 基本授权方案（Basic Authentication Scheme）
用户代理必须对于每个领域（realm）通过用户标识（user-ID）及口令来对自身进行授
权，这是基本授权方案的工作模式。Realm值应当被看作不透明的字符串，该值将用于同服
务器端其它的realm值相比较。只有用户标识及口令通过受保护资源的认证，服务器才会给
请求授权。授权参数没有可选项。
在接收到对受保护区域的未经认证的资源请求时，服务器应当回应一个质询
（challenge），如下：
WWW-Authenticate: Basic realm="WallyWorld"
"WallyWorld"是由服务器分配的字符串，用于对请求URI所指定的受保护资源进行标
识。
为了接收授权，客户端需要在基于64位（base64 [5]）的证书中发送用户标识及口令，
中间用冒号':'分隔。
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64 [5] encoding of userid-password,
except not limited to 76 char/line>
userid-password = [ token ] ":" *TEXT
如果用户代理希望发送用户标识"Aladdin"和口令“open sesame”，应当遵循下面的标题
域形式：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic授权方案是对HTTP服务器资源的非授权访问进行过滤的非安全方法。它基于假
定客户端与服务器端的连接是安全的，为什么说是假定呢，因为在实际的开放性网络中，使
用basic授权方案往往存在许多不安全的地方。尽管如此，客户端仍然需要实现此方案，以
与采用此种方案的服务器进行通讯。
12. 安全考虑（Security Considerations）
本节的描述对下面各角色有关：信息应用开发者、信息提供者、HTTP/1.0中受安全性
限制的用户。本节仅是讨论安全问题，并对减少隐患提出了建议，但是并不提供对问题的最
终解决办法。
12.1 客户授权（Authentication of Clients）
正如11.1节中所述，基本授权（Basic authentication）方案不是安全的用户授权方案，
也不能用它来防止实体主体源码以文本方式在物理网络中传输。HTTP/1.0并不反对在目前
日益突出的安全问题面前采用其它的授权方式及加密机制。
12.2 安全方法（Safe Methods）
客户端软件开发者应当注意，客户端软件代表用户在Internet上与其它方面交互，并应
注意避免让用户知道其间发生的具体动作，这些动作可能会暴露对交互各方有重要意义的信
息。
特别情况下，按协定来看，GET和HEAD方法应被视作是安全的，同重新获得数据应
当没有什么不同。这就允许用户代理采用其它方法，如POST，在某种情况下，可能存在这
样一种情况，即请求中包含不安全的行为。
通常，服务器端在执行过GET请求之后，其结果之类的副产品还残留在服务器上；实
际上，一些动态资源需要这种特性来实现。这里的重要区别在于用户没有请求这些副产品，
因而也不应当对这类请求进行解释。
12.3 服务器日志信息的弊端（Abuse of Server Log
Information）
服务器为保存与用户请求相关的个人数据，如阅读方式或感兴趣的主题等提供了空间。
这些存储信息显然是受某些国家法律保护的，所以对此类数据的处理应当小心。用HTTP
协议提供数据的一方应当负责保证这些信息在未得各方许可之前不会散布出去。
12.4 敏感信息传输（Transfer of Sensitive Information）
与其它协议一样，HTTP协议不能调整传输数据的内容，也不存在未卜先知的方法，通
过给定请求的上下文信息片段就能推测出信息的敏感程度。因而，应用程序应当尽可能像信
息提供方一样，为该信息提供更多的控制。在此，有三个标题域值得一提：服务端（Server）、
提交方（Referer）和来自（From）。
一些指定服务器软件的版本有启示作用，因为这些版本的软件存在一些安全漏洞，将使
服务器更易受到攻击。提倡服务器软件在实现时，将Server标题域变成可以进行配置的选
项。
提交方（Referer）标题域允许阅读方式（reading patterns）被暴露，并可导出反向链接。
虽然该域很有用，但是如果包含在此域的用户信息如果没有被分开，则它的作用很可能被滥
用。另外，即使此域中用户信息被清除，从该域的其它信息仍可推测出其私有文件的URI，
这可能是该信息发布者所不想看到的。
来自（From）标题域可能包括一些与用户私人隐私及站点安全相关的信息，因而，在
发送数据前，应当允许用户使用一些设定手段，如禁止（disable）、允许（enable）、及修改
（modify），对此域信息进行配置。用户应当能够根据他们的选择或使用应用程序提供的缺
省配置来设定此域的内容。
我们建议，但不做要求：为用户提供方便的界面来允许（enable）或禁止（disable）发
送From域或Referer域的信息。
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的内容。
该文档从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.
[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.
[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
附录（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）做为终止符情况。
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，这样就使实际的处理更加复杂。
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应用程序进行
交互。
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类型的所有
子类型。对于给定请求的上下文，客户端应当表示出哪些类型是它可以接受的。
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服务器
不加选择地发送此域，导致此域已经被废弃。
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一定能够找到指定
的资源。
RFC1945——Hyptertext Transfer Protocol – HTTP/1.0 超文本传输协议1.0
1
RFC文档中文翻译计划