About site: Internet/RFCs/2101 - 2200 - RFC 2145
Return to Computers also Computers
  About site: http://www.faqs.org/rfcs/rfc2145.html

Title: Internet/RFCs/2101 - 2200 - RFC 2145 Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R. Fielding, J. Gettys, et al. May 1997.
CybernetFinder Professional web hosting and design with free front page extensions and domain registration.

eSentire,_Inc_ A managed security service provider offering intrusion detection services, vulnerability assessments, independent software code reviews and infrastructure analysis.

Garbage_Dump_Computing By Justin Hayward.

First_Monday_-_What_Next_for_Internet_Journals? One method of article discovery for free online journals has been through the use of Internet search engines. What happens to the accessibility of these journals with the advent of paid placement, inc

Duisoft Enterprise Instant Messaging (EIM) applications all featuring a dialog user interface and instant broadcast and response capabilities - providing means to extend enterprise applications to the mobile

RFC_1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, T. Li, Editors. December 1995.

  Alexa statistic for http://www.faqs.org/rfcs/rfc2145.html





Get your Google PageRank






Please visit: http://www.faqs.org/rfcs/rfc2145.html
  Related sites for http://www.faqs.org/rfcs/rfc2145.html
    Automatic_Language_Identification_Bibliography Research into the automatic identification of spoken language with links to author home pages and online papers.
    FreezeHosting_net Shared and reseller web site hosting supporting PHP, MySQL, PHP, Perl, cgi-bin, Frontpage extensions etc.
    James,_Grant_-_Zeus_CMD Tutorials on C++, Java, Photoshop, 3DMax, Visual Basic.NET, HTML.
    Trusted_Systems_Services A secure systems consulting, service, and training company specializing in Windows NT security. Provides NT security products and publications.
    BuildIT Donation-Ware - A Windows program for managing and executing sequences of tasks. Features library of predefined task types, a general-purpose Visual Basic scripting task type for complex tasks, and lo
    MDaemon Scalable Windows email server with built-in spam blocking, content and antivirus filtering. Includes full mailing list functions, remote administration and support for browser based mail clients.
    Karbusicky_Peter Delphi components, Java applets, JavaScript scripts with sources. Pictures.
    IE_Password_1_5 Password recovery software for Internet Explorer. The program can reveal any password that is stored in IE, but masked like ******.
    RMS_Telecommunications Offers real-time call accounting software for universities, hotels, or any organization that has a PBX capable of generating SMDR data.
    The_USERTRUST_Network A Public Key Infrastructure providing SSL Certificates and Digital Signatures.
    6-BC A Stereo 6 Band VST compressor plug-in from DyVision Works Software.
    Upload_co_il Provides developers with a place to upload, meet, share, exchange ideas and codes, build, improve, bug-fix, read, redistribute, and modify the source code of contributions submitted to the site.
    Canada_Online Offering CD-R duplication and CD duplication systems and kits, copiers, printers and CD-R media.
    Rockler_com_-__Affiliates_Program Online hardware store. Includes programs details, commission rates, and signup form.
    COBOL_Language This document provides the X/Open definition of the COBOL Language which is that set of COBOL Language facilities that programmers should follow when using COBOL compilers on conformant systems. The X
    King_Girl_Media Provides design, java, CGI, marketing research, logo design, stock photography, and sound architecture media services.
    1_Cog Design, hosting, domain registration, search engine optimization. Bristol, England.
    ScottWeb_Design Providing website design, site hosting and promotion for small business in the United Kingdom. Based in Cheshunt, Hertfordshire, England.
    Rental_and_Lease_Agreement_Forms_and_More_in_Microsoft_Word_Format Rental Agreement Forms and Applications are just a couple of the many valuable tools in this Microsoft Word download package. These forms are a must have for today's landlord and are very simple to u
    Spamlook_2003 Bayesian spam filter specifically for POP3 accounts and Microsoft Outlook 2000/2002/2003.
This is websites2007.org cache of m/ as retrieved on 2008.09.07 websites2007.org's cache is the snapshot that we took of the page as we crawled the web. The page may have changed since that time.
RFC 2145 (rfc2145) - Use and Interpretation of HTTP Version Numbers@import 'http://faqs.org/abstracts/css/default.css';@import 'http://faqs.org/search.css';function erfc(s){document.write("[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]Alternate Formats: rfc2145.txt | rfc2145.txt.pdfRFC 2145 - Use and Interpretation of HTTP Version NumbersSearch the Archives Display RFC by number     

RFC2145 - Use and Interpretation of HTTP Version Numbers

Network Working Group J. C. MogulRequest for Comments: 2145 DECCategory: Informational R. Fielding UC Irvine J. Gettys DEC H. Frystyk MIT/LCS May 1997 Use and Interpretation of HTTP Version NumbersStatus 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. . . . . . . . . . . . . . . . . . . . . . . 61 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. RFC 1945, 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. RFC 2068, 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. RFC 791, 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 Previous: RFC 2144 - The CAST-128 Encryption Algorithm Next: RFC 2146 - U.S [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ] © 2008 FAQS.ORG. All rights reserved. 
 

Use

and

Interpretation

of

HTTP

Version

Numbers.

J.

C.

Mogul,

R.

Fielding,

J.

Gettys,

et

al.

May

1997.

http://www.faqs.org/rfcs/rfc2145.html

RFC 2145 2008 September

dvd rental

dvd


Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R. Fielding, J. Gettys, et al. May 1997.

Rules

© 2008 Internet Explorer 5+ or Netscape 6+
Recommended Sites: 1. Arts - Business - Computers - Games - Health - Home - Kids and Teens - News - Recreation - Reference - Regional - Science - Shopping - Society - Sports - World Miss Gallery - Top Anime Hentai - DVD rental by mail - New Hampshire Flags - Ringtones - MPAA - Ringtones - Registro de dominios
2008-09-07 07:30:03

Copyright 2005, 2006 by Webmaster
Websites is cool :) 290Hotel Hannover - Cv Wzory - Soundproofing - Hotel Benidorm - Limuzyna Do Wynajęcia