分享
 
 
 

RFC2145 - Use and Interpretation of HTTP Version Numbers

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group J. C. Mogul

Request for Comments: 2145 DEC

Category: Informational R. Fielding

UC Irvine

J. Gettys

DEC

H. Frystyk

MIT/LCS

May 1997

Use and Interpretation of

HTTP Version Numbers

Status of this Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

Distribution of this document is unlimited. Please send comments to

the HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions

of the working group are archived at

<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions

about HTTP and the applications which use HTTP should take place on

the <www-talk@w3.org> mailing list.

Abstract

HTTP request and response messages include an HTTP protocol version

number. Some confusion exists concerning the proper use and

interpretation of HTTP version numbers, and concerning

interoperability of HTTP implementations of different protocol

versions. This document is an attempt to clarify the situation. It

is not a modification of the intended meaning of the existing

HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention

of the authors of those documents, and can be considered definitive

when there is any ambiguity in those documents concerning HTTP

version numbers, for all versions of HTTP.

TABLE OF CONTENTS

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 Robustness Principle . . . . . . . . . . . . . . . . . . 3

2 HTTP version numbers. . . . . . . . . . . . . . . . . . . . . . 3

2.1 Proxy behavior. . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Compatibility between minor versions of the same major

version. . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Which version number to send in a message. . . . . . . . 5

3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6

4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 Authors' addresses. . . . . . . . . . . . . . . . . . . . . . . 6

1 Introduction

HTTP request and response messages include an HTTP protocol version

number. According to section 3.1 of the HTTP/1.1 specification [2],

HTTP uses a "<major>.<minor>" numbering scheme to indicate

versions of the protocol. The protocol versioning policy is

intended to allow the sender to indicate the format of a message

and its capacity for understanding further HTTP communication,

rather than the features oBTained via that communication. No

change is made to the version number for the addition of message

components which do not affect communication behavior or which

only add to extensible field values. The <minor> number is

incremented when the changes made to the protocol add features

which do not change the general message parsing algorithm, but

which may add to the message semantics and imply additional

capabilities of the sender. The <major> number is incremented when

the format of a message within the protocol is changed.

The same language appears in the description of HTTP/1.0 [1].

Many readers of these documents have eXPressed some confusion about

the intended meaning of this policy. Also, some people who wrote

HTTP implementations before RFC1945 [1] was issued were not aware of

the intentions behind the introduction of version numbers in

HTTP/1.0. This has led to debate and inconsistency regarding the use

and interpretation of HTTP version numbers, and has led to

interoperability problems in certain cases.

This document is an attempt to clarify the situation. It is not a

modification of the intended meaning of the existing HTTP/1.0 and

HTTP/1.1 documents, but it does describe the intention of the authors

of those documents. In any case where either of those two documents

is ambiguous regarding the use and interpretation of HTTP version

numbers, this document should be considered the definitive as to the

intentions of the designers of HTTP.

The specification described in this document is not part of the

specification of any individual version of HTTP, such as HTTP/1.0 or

HTTP/1.1. Rather, this document describes the use of HTTP version

numbers in any version of HTTP (except for HTTP/0.9, which did not

include version numbers).

No vendor or other provider of an HTTP implementation should claim

any compliance with any IETF HTTP specification unless the

implementation conditionally complies with the rules in this

document.

1.1 Robustness Principle

RFC791 [4] defines the "robustness principle" in section 3.2:

an implementation must be conservative in its sending

behavior, and liberal in its receiving behavior.

This principle applies to HTTP, as well. It is the fundamental basis

for interpreting any part of the HTTP specification that might still

be ambiguous. In particular, implementations of HTTP SHOULD NOT

reject messages or generate errors unnecessarily.

2 HTTP version numbers

We start by restating the language quoted above from section 3.1 of

the HTTP/1.1 specification [2]:

It is, and has always been, the explicit intent of the

HTTP specification that the interpretation of an HTTP message

header does not change between minor versions of the same major

version.

It is, and has always been, the explicit intent of the

HTTP specification that an implementation receiving a message

header that it does not understand MUST ignore that header. (The

Word "ignore" has a special meaning for proxies; see section 2.1

below.)

To make this as clear as possible: The major version sent in a

message MAY indicate the interpretation of other header fields. The

minor version sent in a message MUST NOT indicate the interpretation

of other header fields. This reflects the principle that the minor

version labels the capability of the sender, not the interpretation

of the message.

Note: In a future version of HTTP, we may introduce a mechanism

that explicitly requires a receiving implementation to reject a

message if it does not understand certain headers. For example,

this might be implemented by means of a header that lists a set of

other message headers that must be understood by the recipient.

Any implementation claiming at least conditional compliance with

this future version of HTTP would have to implement this

mechanism. However, no implementation claiming compliance with a

lower HTTP version (in particular, HTTP/1.1) will have to

implement this mechanism.

This future change may be required to support the Protocol

Extension Protocol (PEP) [3].

One consequence of these rules is that an HTTP/1.1 message sent to an

HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be

constructed so that it remains a valid HTTP/1.0 message when all

headers not defined in the HTTP/1.0 specification [1] are removed.

2.1 Proxy behavior

A proxy MUST forward an unknown header, unless it is protected by a

Connection header. A proxy implementing an HTTP version >= 1.1 MUST

NOT forward unknown headers that are protected by a Connection

header, as described in section 14.10 of the HTTP/1.1 specification

[2].

We remind the reader that that HTTP version numbers are hop-by-hop

components of HTTP messages, and are not end-to-end. That is, an

HTTP proxy never "forwards" an HTTP version number in either a

request or response.

2.2 Compatibility between minor versions of the same major version

An implementation of HTTP/x.b sending a message to a recipient whose

version is known to be HTTP/x.a, a < b, MAY send a header that is not

defined in the specification for HTTP/x.a. For example, an HTTP/1.1

server may send a "Cache-control" header to an HTTP/1.0 client; this

may be useful if the immediate recipient is an HTTP/1.0 proxy, but

the ultimate recipient is an HTTP/1.1 client.

An implementation of HTTP/x.b sending a message to a recipient whose

version is known to be HTTP/x.a, a < b, MUST NOT depend on the

recipient understanding a header not defined in the specification for

HTTP/x.a. For example, HTTP/1.0 clients cannot be expected to

understand chunked encodings, and so an HTTP/1.1 server must never

send "Transfer-Encoding: chunked" in response to an HTTP/1.0 request.

2.3 Which version number to send in a message

The most strenuous debate over the use of HTTP version numbers has

centered on the problem of implementations that do not follow the

robustness principle, and which fail to produce useful results when

they receive a message with an HTTP minor version higher than the

minor version they implement. We consider these implementations

buggy, but we recognize that the robustness principle also implies

that message senders should make concessions to buggy implementations

when this is truly necessary for interoperation.

An HTTP client SHOULD send a request version equal to the highest

version for which the client is at least conditionally compliant, and

whose major version is no higher than the highest version supported

by the server, if this is known. An HTTP client MUST NOT send a

version for which it is not at least conditionally compliant.

An HTTP client MAY send a lower request version, if it is known that

the server incorrectly implements the HTTP specification, but only

after the client has determined that the server is actually buggy.

An HTTP server SHOULD send a response version equal to the highest

version for which the server is at least conditionally compliant, and

whose major version is less than or equal to the one received in the

request. An HTTP server MUST NOT send a version for which it is not

at least conditionally compliant. A server MAY send a 505 (HTTP

Version Not Supported) response if cannot send a response using the

major version used in the client's request.

An HTTP server MAY send a lower response version, if it is known or

suspected that the client incorrectly implements the HTTP

specification, but this should not be the default, and this SHOULD

NOT be done if the request version is HTTP/1.1 or greater.

3 Security Considerations

None, except to the extent that security mechanisms introduced in one

version of HTTP might depend on the proper interpretation of HTTP

version numbers in older implementations.

4 References

1. Berners-Lee, T., R. Fielding, and H. Frystyk. Hypertext

Transfer Protocol -- HTTP/1.0. RFC1945, HTTP Working Group, May,

1996.

2. Fielding, Roy T., Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk

Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --

HTTP/1.1. RFC2068, HTTP Working Group, January, 1997.

3. Khare, Rohit. HTTP/1.2 Extension Protocol (PEP). HTTP Working

Group, Work in Progress.

4. Postel, Jon. Internet Protocol. RFC791, NIC, September, 1981.

5 Authors' addresses

Jeffrey C. Mogul

Western Research Laboratory

Digital Equipment Corporation

250 University Avenue

Palo Alto, California, 94305, USA

Email: mogul@wrl.dec.com

Roy T. Fielding

Department of Information and Computer Science

University of California

Irvine, CA 92717-3425, USA

Fax: +1 (714) 824-4056

Email: fielding@ics.uci.edu

Jim Gettys

MIT Laboratory for Computer Science

545 Technology Square

Cambridge, MA 02139, USA

Fax: +1 (617) 258 8682

Email: jg@w3.org

Henrik Frystyk Nielsen

W3 Consortium

MIT Laboratory for Computer Science

545 Technology Square

Cambridge, MA 02139, USA

Fax: +1 (617) 258 8682

Email: frystyk@w3.org

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有