Hypertext Transfer Protocol Bis (httpbis) Internet Drafts
| HTTP/1.1,part 1: URIs,Connections,and Message Parsing | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. | ||||||||||||||||
| HTTP/1.1,part 2: Message Semantics | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields. | ||||||||||||||||
| HTTP/1.1,part 3: Message Payload and Content Negotiation | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. | ||||||||||||||||
| HTTP/1.1,part 4: Conditional Requests | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. | ||||||||||||||||
| HTTP/1.1,part 5: Range Requests and Partial Responses | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. | ||||||||||||||||
| HTTP/1.1,part 6: Caching | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. | ||||||||||||||||
| HTTP/1.1,part 7: Authentication | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication. | ||||||||||||||||
| Security Requirements for HTTP | |||||||||||||||||
|
Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade- offs of each. | ||||||||||||||||
| Initial Hypertext Transfer Protocol (HTTP) Method Registrations | |||||||||||||||||
|
This document registers those Hypertext Transfer ProtocolHypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
Hypertext Transfer Protocol Bis (httpbis)
Last Modified: 2008-08-21
Additional information is available at tools.ietf.org/wg/httpbis
Chair(s):
Applications Area Director(s):
Applications Area Advisor:
Mailing Lists:
General Discussion: ietf-http-wg@w3.orgTo Subscribe: http://lists.w3.org/Archives/Public/ietf-http-wg/
Archive:
Description of Working Group:
HTTP is one of the most successful and widely-used protocols on theInternet today. However, its specification has several editorial
issues. Additionally, after years of implementation and extension,
several ambiguities have become evident, impairing interoperability
and the ability to easily implement and use HTTP.
The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries,
ABNF)
* Fix editorial problems which have led to misunderstandings of the
specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented
and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated
echanisms (e.g., Basic and Digest authentication, cookies, TLS) for
common applications
In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments
The Working Group must not introduce a new version of HTTP and should
not add new functionality to HTTP. The WG is not tasked with producing
new methods, headers, or extension mechanisms, but may introduce new
protocol elements if necessary as part of revising existing
functionality which has proven to be problematic
The Working Group's specification deliverables are:
* A document that is suitable to supersede RFC 2616
* A document cataloguing the security properties of HTTP
Goals and Milestones:
| Done | First HTTP Revision Internet Draft | |
| Feb 2008 | First HTTP Security Properties Internet Draft | |
| Jun 2008 | Request Last Call for HTTP Revision | |
| Jul 2008 | Request Last Call for HTTP Security Properties | |
| Oct 2008 | Submit HTTP Revision to IESG for consideration as a Draft Standard | |
| Oct 2008 | Submit HTTP Security Properties to IESG for consideration as Informational |
Internet-Drafts:
HTTP/1.1, part 1: URIs, Connections, and Message Parsing (164098 bytes)HTTP/1.1, part 2: Message Semantics (116627 bytes)
HTTP/1.1, part 3: Message Payload and Content Negotiation (92188 bytes)
HTTP/1.1, part 4: Conditional Requests (49575 bytes)
HTTP/1.1, part 5: Range Requests and Partial Responses (43519 bytes)
HTTP/1.1, part 6: Caching (116462 bytes)
HTTP/1.1, part 7: Authentication (26767 bytes)
Security Requirements for HTTP (25757 bytes)
Initial Hypertext Transfer Protocol (HTTP) Method Registrations (9955 bytes)
No Request For Comments
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
