All, Attached in a very very early draft of an alternative proposal for a transfer protocol for HTML5 WebSockets. For lack of a better name (and not wanting to coopt the hybi name), I've called it BWTP - Bidirection Web Transfer Protocol I wont explain the protocol here, as hopefully the proposal document does that sufficiently well. But I will explain why I think this proposal (or something approximately similar) is superior to the current Websocket protocol proposal: + The protocol is very much an IETF style application protocol. In fact it is just RFC2616 with anything non bidirectional ripped out. It is not trying to be a revolution in web protocols, but simply to solve the problems at hand. + The protocol document is written very much in IETF style. In fact it is just RFC2616 with anything non bidirectional ripped out. BNF is used to specify the protocol and the principal of "be strict in what you generate and forgiving in what your parse" is adhered to. + Because of it's similarity to HTTP, it is intended that existing HTTP clients, servers and intermediaries will be able to be minimally updated to support this protocol. This will not require entirely new protocol libraries to be developed. Existing development and analysis tools will also be able to be easily updated, plus the protocol is mostly human readable. + It supports full mime encapsulated payloads, but has a default mechanism so that most values only need to be specified once per connection if they do not change. The minimal overhead per message is 11 bytes, which is a little more than the websocket proposal, but is hardly significant. + There is no formal channel mechanism like BEEP has, but each message may be to/from a different URI if need be. This makes multiplexing easy to support. + There is no formal segmentation mechanism, but Content-Ranges are supported so that large content cna be sent in smaller bits if desired. + The protocol recognizes that intermediaries (proxies) may wish to be an active party on a bi direction connection. For example, this proposal allows an intermediary to initiate and orderly lossless close of the connection. I'm sure innovative proxy applications will be developed over time, just as they have been for HTTP. + it well supports the current HTML WebSocket API but is also flexible and extensible so that non browser clients may use it and future APIs will not need protocol changes. I'd really appreciate any feedback, co-authors, review, editing etc. I don't consider anything in this proposal to be fixed and all is open to change. I have the draft in Google Docs and am happy to add collaborators (there are a few already (who should add themselves to the authors/acknowlegements)). cheers
Greg Wilkins
Bidirectional Web Transfer Protocol -- BWTP/1.0
Status of this Memo
This document is written by somebody who knows nothing of IETF
procedures. It is desperately in need of co-authors and review.
It is intended to be an alternative proposal for the
transport protocol for the WebSocket API from HTML 5.
This document is heavily based on RFC2616 and borrow structure,
ideas and text from that document.
currently the formatting is all manual and the section numbering
has been kept similar to RFC2616
Copyright Notice
Copyright (C) The Internet Society (2009). All Rights Reserved.
Abstract
The Bidirectional Web Transfer Protocol (HTTP) is an application-level
protocol that can be used to upgrade an RFC2616 HTTP connection
to a bidirectional channel capable of exchanging messages.
Table of Contents
TBD
1 Introduction
1.1 Purpose
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, but it is intrinsically a
request/response protocol and cannot well service the growing
use-case for data to be pushed from a server to a client.
The Bidirectional Web Transfer Protocol (BWTP) is an application-level
protocol that can be used to upgrade a HTTP/1.1 connection to
be able to exchange bidirectional MIME-like messages,
containing metainformation about the data transferred.
Messages are passed in a format similar to that used by HTTP/1.1
as defined by RFC2616. It is intended that implementations
of HTTP clients, servers and intermediaries will be able to
be minimally updated in order to support BWTP.
1.2 Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [34].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the MUST
level requirements but not all the SHOULD level requirements for its
protocols is said to be "conditionally compliant."
1.3 Terminology
This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP or BWTP communication.
connection
A transport layer virtual circuit established between two programs
for the purpose of communication.
message
The basic unit of BWTP communication, consisting of a structured
sequence of octets matching the syntax defined in section 4 and
transmitted via the connection.
request
An HTTP request message, as defined in section 5 of RFC 2616.
response
An HTTP response message, as defined in section 6 of RFC 2616.
resource
A network data object or service that can be identified by a URI,
as defined in section 3.2. Resources may be available in multiple
representations (e.g. multiple languages, data formats, size, and
resolutions) or vary in other ways.
client
A program that establishes connections for the purpose of sending
requests.
user agent
The client which initiates a connection. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
server
An application program that accepts connections.
Any given program may
be capable of being both a client and a server; our use of these
terms refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities
in general. Likewise, any server may act as an origin server,
proxy, gateway, or tunnel, switching behavior based on the nature
of each message.
origin server
The server on which a given resource resides or is to be created.
proxy
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy MUST implement
both the client and server requirements of this specification. A
"transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification. A "non-transparent proxy" is a proxy that modifies
the request or response in order to provide some added service to
the user agent, such as group annotation services, media type
transformation, protocol reduction, or anonymity filtering. Except
where either transparent or non-transparent behavior is explicitly
stated, the HTTP proxy requirements apply to both types of
proxies.
gateway
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections are closed.
upstream/downstream
Upstream and downstream describe the flow of a message: all
messages flow from upstream to downstream.
inbound/outbound
Inbound and outbound refer to the request and response paths for
messages: "inbound" means "travelling toward the origin server",
and "outbound" means "travelling toward the user agent"
1.4 Overall Operation
The BWTP protocol is a HTTP upgrade protocol. A clients a HTTP
upgrade request to the server in order to establish a BWTP connection.
After successful upgrade, the BWTP connection is a bidirectional
stream of MIME-like messages. There is no relationship between
inbound and outbound messages.
The upgrade request and response may define meta data defaults
for all messages on a BWTP connection, such as content-type,
character-set, content-encoding, Location and Origin.
Individual messages my override any or all of these
defaults as well as provide additional meta-data that does not
have defaults.
BWTP communication is initiated by a user agent and consists of
an upgrade request to be applied to a resource on some origin server.
In the simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O).
UA -------------------v------------------- O
upgrade request ----------------------»
«----------------- 101 upgrade response
inbound messages ---------------------»
«-------------------- outbound messages
Inbound and outbound messages may be sent simultaneously.
A more complicated situation occurs when one or more intermediaries
are present in the request/response chain. There are three common
forms of intermediary: proxy, gateway, and tunnel. A proxy is a
forwarding agent, receiving a message for a URI in its absolute form,
rewriting all or part of the message, and forwarding the reformatted
request toward the server identified by the URI. A gateway is a
receiving agent, acting as a layer above some other server(s) and, if
necessary, translating the requests to the underlying server's
protocol. A tunnel acts as a relay point between two connections
without changing the messages; tunnels are used when the
communication needs to pass through an intermediary (such as a
firewall) even when the intermediary cannot understand the contents
of the messages.
UA -----v----- A -----v----- B -----v----- C -----v----- O
upgrade request ------------------------------------»
«------------------------------- 101 upgrade response
inbound messages -----------------------------------»
«---------------------------------- outbound messages
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. All intermediaries must accept
the initial upgrade request and pass it onwards towards the
origin server. If any intermediary does not understand the
upgrade request, the BWTP connection will not be established.
A message that travels the whole chain will pass through four
separate connections.
This distinction is important because some BWTP communication
options may apply only to the connection with the nearest, non-tunnel
neighbour, only to the end-points of the chain, or to all connections
along the chain.
Although the diagram is linear, each participant may
be engaged in multiple, simultaneous communications. For example, B
may be receiving requests from many clients other than A, and/or
forwarding requests to servers other than C, at the same time that it
is handling A's request.
Any party to the communication which is not acting as a tunnel may
inject messages into either the inbound or outbound stream.
The following illustrates if B has injects both an inbound
and an outbound message:
UA -----v----- A -----v----- B -----v----- C -----v----- O
upgrade request ------------------------------------»
«------------------------------- 101 upgrade response
inbound messages -----------------------------------»
«---------------------------------- outbound message»
«-------outbound message--|--inbound message -------»
inbound messages -----------------------------------»
«---------------------------------- outbound messages
BWTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does
not preclude BWTP from being implemented on top of any other protocol
on the Internet, or on other networks. BWTP only presumes a HTTP
connection can be established over a reliable transport;
any protocol that provides such guarantees can be used.
2 Notational Conventions and Generic Grammar
2.1 Augmented BNF
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) as defined by
section 2.1 of RFC 2616.
Implementers will need to be familiar with the
notation in order to understand this specification.
2.2 Basic Rules
The Basic Rules as defined by section 2.2 of RFC 2616 are used
throughout this specification to describe basic parsing constructs.
The US-ASCII coded character set is defined by ANSI X3.4-1986 [21].
3 Protocol Parameters
3.1 BWTP Version
BWTP 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 BWTP 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. See RFC 2145 [36] for a fuller explanation.
All messages on a BWTP connection will be of the same version
that is negotiated with the upgrade request and response that
establishes the BWTP connection:
BWTP-Version = "BWTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers MUST be treated as separate
integers and that each MAY be incremented higher than a single digit.
Thus, BWTP/2.4 is a lower version than BWTP/2.13, which in turn is
lower than BWTP/12.3. Leading zeros MUST be ignored by recipients and
MUST NOT be sent.
The BWTP version of a connection is the highest BWTP version for
which all intermediaries and the agent and origin server can handle.
3.2 Uniform Resource Identifiers
URIs as defined by 3.2 of RFC2616 are used to identify BWTP
resources.
3.4 Character Sets
BWTP uses the same definition of the term "character set" as that
described in section 3.4 of RFC2616.
3.4.1 Missing Charset
If not otherwise specified, a character set of UTF-8 may be assumed.
3.5 Content Codings
The content codings defined by section 3.5 of RFC2616 and
registered with the Internet Assigned Numbers Authority (IANA)
MAY be applied to a BWTP message.
3.6 Transfer Codings
HTTP-like transfer codings MUST NOT be applied to BWTP
connections or messages. Specifically the chunked transfer
encoding is not supported by BWTP; Range limited messages
should be sent in situations where chunked transfer is
desirable.
3.7 Media Types
HTTP uses Internet Media Types [17] in the Content-Type
header field in order to provide open and extensible data typing
and type negotiation. The media-type is defined in section
3.7 of RFC2616 as:
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
3.12 Range Units
BWTP allows a message to carry only a part of an identified resource.
BWTP uses range units in the Content-Range header field. A range-unit
is defined in section 3.12 of RFC2616 as:
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
An entity can be broken down into subranges according
to various structural units.
The only range unit defined by BWTP/1.0 is "bytes". BWTP/1.0
implementations MAY ignore ranges specified using other units.
BWTP/1.0 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.
4 BWTP Message
4.1 Message Types
BWTP messages consist of inbound messages from client to server and
outbound message from the server to client:
BWTP-message = Inbound-message | Outbound-message ; BWTP/1.0 messages
4.2 Generic Messages
Inbound and Outbound messages use the generic message format of
RFC 822 [9] for transferring entities (the payload
of the message). Both types of message consist of a start-line, zero
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body.
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
[ *CRLF ]
start-line = "BWTP" SP message-URI SP content-length
message-URI = "*" ; the connection default resource
| absoluteURI
| abs_path
content-length = 1*DIGIT
In the interest of robustness, servers and clients SHOULD ignore any empty
line(s) received where a start-line is expected.
4.2 Message Headers
BWTP header fields follow the same generic format as
that given in Section 3.1 of RFC 822 [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive. The field value MAY be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications ought to follow "common form", where
one is known or indicated, when generating HTTP constructs, since
there might exist some implementations that fail to accept anything
beyond the common forms.
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = «the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string»
The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message
downstream.
The order in which header fields with differing field names are
received is not significant.
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
4.3 Message Body
The presence of a message-body in a request is signalled by a non
zero content-length in the message start-line. If a Content-Length
field is included in the message-headers, it is ignored.
The message body is defined as
message-body = *OCTET
4.4 Message Length
The message body length is determined by the content-length
specified in the message start-line.
4.5 General Header Fields
There are a few header fields which have general applicability for
both inbound and outbound messages, but which do not apply to the
entity being transferred. These header fields apply only to the
message being transmitted.
general-header = Connection
| Date
| Via
General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity-header fields.
5 Inbound Message
An inbound message from a client to a server is a generic
message with the restriction of the included headers to be
either general, inbound or entity headers:
inbound-request = "BWTP" SP message-URI SP content-length
*(( general-header | inbound-header | entity-header ) CRLF)
CRLF
[ message-body ]
[ CRLF ]
5.1 Inbound Message URI
The inbound message-URI is a Uniform Resource Identifier and
identifies the resource on the origin server to which the
message is destined. A message-URI of "*" means that the
default URI of the connection.
If the abs_path form is used for the inbound message URI, then
the host of the resource is defined either by a Host header
in the message or a Host header in the original upgrade request.
The inbound message URI is not used by proxies to route messages.
A message, even with an absolute URI or Host header that specifies
a different origin server will be delivered to the origin server
identified in the original upgrade request.
If the message-URI is encoded using the "% HEX HEX" encoding
[42], the origin server MUST decode the Request-URI in order to
properly interpret the request.
5.3 Inbound Header Fields
The inbound-header fields allow the client to pass additional
information about the message, and about the client itself, to the
server. These fields act as message modifiers, with semantics
equivalent to the parameters on a programming language method
invocation.
inbound-header = Authorization
| Host
| Origin
| Proxy-Authorization
| User-Agent
| Cookie ; TODO Maybe not?
inbound-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
entity-header fields.
5.4 Inbound Message Examples
A minimal inbound message with default destination and
content-type is
BWTP * 12
Hello World!
An inbound message with default destination and content-type
and a content range
BWTP * 5
Content-Range: bytes 1-5/12
Hello
An inbound message that explicitly identifies a destination,
content type and content encoding is
BWTP /destination/path 12
Content-Type: text/plain;charset=utf-8
Hello World!
An empty message with a Connection header:
BWTP * 0
Connection: close
6 Outbound Message
An outbound message from a server to a client is a generic
message with the restriction of the included headers to be
either general, outbound or entity headers:
inbound-request = "BWTP" SP message-URI SP content-length
*(( general-header | outbound-header | entity-header ) CRLF)
CRLF
[ message-body ]
[ CRLF ]
6.1 Outbound Message URI
The outbound message-URI is a Uniform Resource Identifier and
identifies the resource on the origin server from which the
message has been sent. A message-URI of "*" means that the
default URI of the connection applies.
If the abs_path form is used for the inbound message URI, then
the host of the resource is defined either by a Host header
in the message or a Host header in the original upgrade request.
The outbound message URI is not used by proxies to route messages.
All outbound messages on a connection will be delivered to the
user agent that initialized the connection.
If the message-URI is encoded using the "% HEX HEX" encoding
[42], the user agent MUST decode the message-URI in order to
properly interpret the message.
6.2 Outbound Header Fields
The outboudn-header fields allow the server to pass additional
information about the message,
These header fields give information about the server and about
further access to the resource identified by the Message-URI.
outbound-header = Location
| Server
| WWW-Authenticate
| Set-Cookie
| Content-Origin TODO - the origin stuff needs more thought
Outbound header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields.
6.3 Outbound Message Examples
A minimal outbound message with default source and
content-type is
BWTP * 12
Hello World!
An outbound message with default destination and content-type
and a content range
BWTP * 5
Content-Range: bytes 1-5/12
Hello
An outbound message that explicitly identifies a source,
content type, content encoding and Origin is
BWTP /destination/path 12
Content-Type: text/plain;charset=utf-8
Origin: www.acme.com
Hello World!
An empty message with a Connection header:
BWTP * 0
Connection: close
7 Entity
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message.
7.1 Entity Header Fields
Entity-header fields define metainformation about the entity-body or,
if no body is present, about the resource identified by the request.
Some of this metainformation is OPTIONAL; some might be REQUIRED by
portions of this specification.
entity-header = Content-Encoding
| Content-Language
| Content-Location
| Content-MD5
| Content-Range
| Content-Type
| Expires
| Last-Modified
| extension-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies.
8 Connections
8.1 Negotiation
8.1.1 Upgrade Request
A BWTP connection is initiated by a client issuing an upgrade request,
which is a valid HTTP/1.1 GET request with an Upgrade header field set
to the desired BWTP-Version:
BWTP-Upgrade-Request = "GET" SP URI SP "HTTP/1.1" CRLF
*(message-header CRLF)
"Upgrade" ":" BWTP-Version
*(message-header CRLF)
CRLF
[ message-body ]
Since Upgrade is only for the immediate connection, the Upgrade Request SHOULD
also contain a Connection header with "Upgrade" in it's values.
The default values for all inbound messages on the resulting BWTP connection
are taken from:
* The default message-URI is the URI of the upgrade request.
* The default host is the host given either in an absolute URI or in a
Host header.
* Any header field with a name starting with "BWTP-" is used as
a default field of all inbound BWTP messages, with the leading
"BWTP-" stripped from the name.
An example Upgrade Request example
GET /path HTTP/1.1
Host: host.com:80
Upgrade: BWTP/1.0
Connection: Upgrade
Origin: the.origin.com
Authorization: BASIC amd73ksosh3hj210sd3d0dk1
BWTP-Content-Type: text/plain;charset=utf-8
This request, if accepted, has the following inbound messages defaults:
message-URI /path
host host.com
port 80
Content-Type text/plain;charset=utf-8
If an intermediary in the HTTP connection accept the upgrade, they MUST
forward the Upgrade header in their requests towards the origin server.
8.1.2 Upgrade Response
When an origin server receives an Upgrade request and the resource specified
by the URI accepts the upgrade, then acceptance is indicated by sending
an Upgrade Response:
BWTP-Upgrade-Response = "HTTP/1.1" SP 101 SP "Bidirectional Web Transfer Protocol" CRLF
*(message-header CRLF)
"Upgrade" ":" BWTP-Version
*(message-header CRLF)
CRLF
The default values for all outbound messages on the resulting BWTP connection
are taken from:
* The default message-URI is the URI of the upgrade request.
* The default host is the host given either in an absolute URI or in a
Host header of the upgrade request.
* Any header field in the response with a name starting with "BWTP-" is used as
a default field of all outbound BWTP messages, with the leading "BWTP-" stripped
from the name.
An example Upgrade Response example is
HTTP/1.1 101 Bidirectional Web Transfer Protocol
BWTP-Content-Origin: the.origin.com
BWTP-Content-Type: text/plain;charset=utf-8
This request, if sent in response to the prior Upgrade Request example, has the
following outbound messages defaults:
message-URI /path
host host.com
port 80
Content-Type text/plain;charset=utf-8
Content-Origin the.origin.com
8.2 Flow Control
BWTP/1.1 servers SHOULD maintain connections and use TCP's
flow control mechanisms to resolve temporary overloads, rather than
terminating connections with the expectation that clients will retry.
The latter technique can exacerbate network congestion.
8.3 Closing Connections
8.3.1 Spontaneous Connection close
Either the client or server or any intermediary MAY at any time
close the BWTP. Message delivery is not guaranteed if a spontaneous
close is performed. Clients, servers and intermediaries SHOULD
use orderly connection close if guaranteed delivery is required.
8.3.2 Orderly Connection close
Either the client or server or any intermediary MAY initiate an
orderly shutdown of a BWTP connection by sending a message with
a "Connection" header field with a value of "Close". After sending
such a message, messages MUST NOT be sent on the connection,
but messages SHOULD continue to be received and processed until
amessage is received that also contains a Connection Close header.
The connection may then be closed.
A client or server that is not closing the connection, on receipt of
any message that contains a Connection Close header should immediately
flush any pending or queued messages for the connection and the last
message sent should have a Connection close header. After sending
the last message, the connection may be closed.
The connection close header may be sent on any valid BWTP message.
If no message is queued or available to carry a close header, then
an empty BWTP message may be sent:
BWTP * 0
Connection: close
11 Access Authentication
HTTP provides several OPTIONAL challenge-response authentication
mechanisms which can be used by a server to challenge a client
request and by a client to provide authentication information. The
general framework for access authentication, and the specification of
"basic" and "digest" authentication, are specified in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. This
specification adopts the definitions of "challenge" and "credentials"
from that specification.
14 Header Field Definitions
15 Security Considerations
16 Acknowledgments
17 References
18 Authors' Addresses
19 Appendices
20 Index
Please see the PostScript version of this RFC for the INDEX.
21. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.