RFC relevance of extension

As per Relevance of the word extension, we have this rfc below:

Network Working Group H.
Request for Comments: 2774 P.
Category: Experimental
S.
Agranat
February 2000

An HTTP Extension

Status of this

This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

IESG

This document was originally requested for Proposed Standard status
However, due to mixed reviews during Last Call and within the
working group, it is being published as an Experimental document
This is not necessarily an indication of technical flaws in
document; rather, there is a more general concern about whether
document actually represents community consensus regarding
evolution of HTTP. Additional study and discussion are needed
this can be determined

Note also that when HTTP is used as a substrate for other protocols
it may be necessary or appropriate to use other extension
in addition to, or instead of, those defined here. This
should therefore not be taken as a blueprint for adding extensions
HTTP, but it defines mechanisms that might be useful in
circumstances

Nielsen, et al. Experimental [Page 1]

RFC 2774 An HTTP Extension Framework February 2000

A wide range of applications have proposed various extensions of
HTTP protocol. Current efforts span an enormous range,
distributed authoring, collaboration, printing, and remote
call mechanisms. These HTTP extensions are not coordinated,
there has been no standard framework for defining extensions
thus, separation of concerns. This document describes a
extension mechanism for HTTP, which is designed to address
tension between private agreement and public specification and
accommodate extension of applications using HTTP clients, servers
and proxies. The proposal associates each extension with a
unique identifier, and uses HTTP header fields to carry the
identifier and related information between the parties involved
the extended communication

Table of

1. Introduction ...............................................3
2. Notational Conventions .....................................3
3. Extension Declarations .....................................4
3.1 Header Field Prefixes ...................................5
4. Extension Header Fields ....................................6
4.1 End-to-End Extensions ...................................7
4.2 Hop-by-Hop Extensions ...................................7
4.3 Extension Response Header Fields ........................8
5. Mandatory HTTP Requests ....................................8
5.1 Fulfilling a Mandatory Request .........................10
6. Mandatory HTTP Responses ..................................11
7. 510 Not Extended ..........................................11
8. Publishing an Extension ...................................11
9. Caching Considerations ....................................12
10. Security Considerations ...................................13
11. References ................................................13
12. Acknowledgements ..........................................14
13. Authors' Addresses ........................................14
14. Summary of Protocol Interactions ..........................15
15. Examples ..................................................16
15.1 User Agent to Origin Server ............................16
15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........17
15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........18
Full Copyright Statement ......................................20

Nielsen, et al. Experimental [Page 2]

RFC 2774 An HTTP Extension Framework February 2000

1.

This proposal is designed to address the tension between
agreement and public specification; and to accommodate
extension of HTTP clients and servers by software components.
kind of extensions capable of being introduced range from

o extending a single HTTP message

o introducing new encodings

o initiating HTTP-derived protocols for new applications; to...

o switching to protocols which, once initiated, run
of the original protocol stack

The proposal is intended to be used as follows

o Some party designs and specifies an extension; the
assigns the extension a globally unique URI, and makes one
more representations of the extension available at that
(see section 8).

o An HTTP client or server that implements this
mechanism (hereafter called an agent) declares the use of
extension by referencing its URI in an extension declaration
an HTTP message (see section 3).

o The HTTP application which the extension declaration
intended for (hereafter called the ultimate recipient)
deduce how to properly interpret the extended message based
the extension declaration

The proposal uses features in HTTP/1.1 but is compatible
HTTP/1.0 applications in such a way that extended applications
coexist with existing HTTP applications. Applications
this proposal MUST be based on HTTP/1.1 (or later versions of HTTP).

2. Notational

This specification uses the same notational conventions and
parsing constructs as RFC 2068 [5]. In particular the BNF
"token", "quoted-string", "Request-Line", "field-name",
"absoluteURI" in this document are to be interpreted as described
RFC 2068 [5].

Nielsen, et al. Experimental [Page 3]

RFC 2774 An HTTP Extension Framework February 2000

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [6].

This proposal does not rely on particular features defined in
[8] that cannot potentially be expressed using URNs (see section 8).
Therefore, the more generic term URI [8] is used throughout
specification

3. Extension

An extension declaration can be used to indicate that an
has been applied to a message and possibly to reserve a part of
header namespace identified by a header field prefix (see 3.1).
section defines the extension declaration itself; section 4 defines
set of header fields using the extension declaration

This specification does not define any ramifications of applying
extension to a message nor whether two extensions can or
logically coexist within the same message. It is simply a
for describing which extensions have been applied and what
ultimate recipient either must or may do in order to
interpret any extension declarations within that message

The grammar for an extension declaration is as follows

ext-decl = <"> ( absoluteURI | field-name ) <">
[ namespace ] [ decl-extensions ]

namespace = ";" "ns" "=" header-
header-prefix = 2*

decl-extensions = *( decl-ext )
decl-ext = ";" token [ "=" ( token | quoted-string ) ]

An extension is identified by an absolute, globally unique URI or
field-name. A field-name MUST specify a header field uniquely
in an IETF Standards Track RFC [3]. A URI can unambiguously
distinguished from a field-name by the presence of a colon (":").

The support for header field names as extension identifiers
a transition strategy from decentralized extensions to
defined by IETF Standards Track RFCs until a mapping between
globally unique URI space and features defined in IETF
Track RFCs has been defined according to the guidelines described
section 8.

Nielsen, et al. Experimental [Page 4]

RFC 2774 An HTTP Extension Framework February 2000

Examples of extension declarations

"http://www.company.com/extension"; ns=11
"Range

An agent MAY use the decl-extensions mechanism to include
extension declaration parameters but cannot assume these
to be recognized by the recipient. An agent MUST NOT use decl
extensions to pass extension instance data, which MAY be passed
header field prefix values (see section 3.1). Unrecognized decl-
parameters SHOULD be ignored and MUST NOT be removed by proxies
forwarding the extension declaration

3.1 Header Field

The header-prefix is a dynamically generated string. All
fields in the message that match this string, using string prefix
matching, belong to that extension declaration. Header field
allow an extension declaration to dynamically reserve a subspace
the header space in a protocol message in order to prevent
field name clashes and to allow multiple declarations using the
extension to be applied to the same message without conflicting

Header fields using a header-prefix are of the form

prefixed-header = prefix-match field-
prefix-match = header-prefix "-"

Linear white space (LWS) MUST NOT be used between the header-
and the dash ("-") or between the prefix-match and the field-name
The string prefix matching algorithm is applied to the prefix-
string

The format of the prefix using a combination of digits and the
("-") guarantees that no extension declaration can reserve the
header field name space. The header-prefix mechanism was
over other solutions for exchanging extension instance
because it is header based and therefore allows for easy
of new extensions with existing HTTP features

Agents MUST NOT reuse header-prefix values in the same message
explicitly allowed by the extension (see section 4.1 for a
of the ultimate recipient of an extension declaration).

Clients SHOULD be as consistent as possible when generating header
prefix values as this facilitates use of the Vary header field
responses that vary as a function of the request
declaration(s) (see [5], section 13.6).

Nielsen, et al. Experimental [Page 5]

RFC 2774 An HTTP Extension Framework February 2000

Servers including prefixed-header header fields in a Vary
field value MUST also include the corresponding extension
field-name as part of that value. For example, if a response
on the value of the 16-use-transform header field defined by
optional extension declaration in the request, the Vary header
in the response could look like this

Vary: Opt, 16-use-

Note, that header-prefix consistency is no substitute for
an extension declaration in the message: header fields with header
prefix values not defined by an extension declaration in the
message are not defined by this specification

Examples of header-prefix values

12
15
23

Old applications may introduce header fields independent of
extension mechanism, potentially conflicting with header
introduced by the prefix mechanism. In order to minimize this risk
prefixes MUST contain at least 2 digits

4. Extension Header

This proposal introduces two types of extension declaration strength
mandatory and optional, and two types of extension declaration scope
hop-by-hop and end-to-end (see section 4.1 and 4.2).

A mandatory extension declaration indicates that the
recipient MUST consult and adhere to the rules given by the
when processing the message or reporting an error (see section 5
7).

An optional extension declaration indicates that the
recipient of the extension MAY consult and adhere to the rules
by the extension when processing the message, or ignore the
declaration completely. An agent may not be able to
whether the ultimate recipient does not understand an
referred to by an optional extension or simply ignores the
declaration

Nielsen, et al. Experimental [Page 6]

RFC 2774 An HTTP Extension Framework February 2000

The combination of the declaration strength and scope defines a 2x
matrix which is distinguished by four new general HTTP header fields
Man, Opt, C-Man, and C-Opt. (See sections 4.1 and 4.2; also
appendix 14, which has a table of interactions with origin
and proxies.)

The header fields are general header fields as they describe
extensions actually are applied to an HTTP message.
declarations MAY be applied to any HTTP message if appropriate (
section 5 for how to apply mandatory extension declarations
requests and section 6 for how to apply them to responses).

4.1 End-to-End

End-to-end declarations MUST be transmitted to the ultimate
of the declaration. The Man and the Opt general header fields
end- to-end header fields and are defined as follows

mandatory = "Man" ":" 1#ext-
optional = "Opt" ":" 1#ext-

For

HTTP/1.1 200
Content-Length: 421
Opt: "http://www.digest.org/Digest"; ns=15
15-digest: "snfksjgor2tsajkt52"
...

The ultimate recipient of a mandatory end-to-end
declaration MUST handle that extension declaration as described
section 5 and 6.

4.2 Hop-by-Hop

Hop-by-hop extension declarations are meaningful only for a
HTTP connection. In HTTP/1.1, C-Man, C-Opt, and all header
with matching header-prefix values defined by C-Man and C-Opt MUST
protected by a Connection header field. That is, these header
are to be included as Connection header field directives (see [5],
section 14.10). The two header fields have the following grammar

c-mandatory = "C-Man" ":" 1#ext-
c-optional = "C-Opt" ":" 1#ext-

Nielsen, et al. Experimental [Page 7]

RFC 2774 An HTTP Extension Framework February 2000

For

M-GET / HTTP/1.1
Host: some.
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df
Connection: C-Man, 14-

The ultimate recipient of a mandatory hop-by-hop
declaration MUST handle that extension declaration as described
section 5 and 6.

4.3 Extension Response Header

Two extension response header fields are used to indicate that
request containing mandatory extension declarations has
fulfilled by the ultimate recipient as described in section 5.1.
extension response header fields are exclusively intended to serve
extension acknowledgements, and can not carry any other information

The Ext header field is used to indicate that all end-to-
mandatory extension declarations in the request were fulfilled

ext = "Ext" ":"

The C-Ext response header field is used to indicate that all hop-by
hop mandatory extension declarations in the request were fulfilled

c-ext = "C-Ext" ":"

In HTTP/1.1, the C-Ext header fields MUST be protected by
Connection header (see [5], section 14.10).

The Ext and the C-Ext header fields are not mutually exclusive;
can both occur within the same message as described in section 5.1.

5. Mandatory HTTP

An HTTP request is called a mandatory request if it includes at
one mandatory extension declaration (using the Man or the C-
header fields). The method name of a mandatory request MUST
prefixed by "M-". For example, a client might express the
rights- management constraints in an HTTP PUT request as follows

Nielsen, et al. Experimental [Page 8]

RFC 2774 An HTTP Extension Framework February 2000

M-PUT /a-resource HTTP/1.1
Man: "http://www.copyright.org/rights-management"; ns=16
16-copyright: http://www.copyright.org/COPYRIGHT.
16-contributions: http://www.copyright.org/PATCHES.
Host: www.w3.
Content-Length: 1203
Content-Type: text/

An ultimate recipient conforming to this specification receiving
mandatory request MUST process the request by performing
following actions in the order listed below

1. Identify all mandatory extension declarations (both hop-by-
and end-to-end); the server MAY ignore optional
without affecting the result of processing the HTTP message

2. Examine all extensions identified in 1) and determine if
are supported for this message. If not, respond with a 510 (
Extended) status-code (see section 7);

3. If 2) did not result in a 510 (Not Extended) status code,
process the request according to the semantics of
extensions and of the existing HTTP method name as defined
HTTP/1.1 [5] or later versions of HTTP. The HTTP method
can be obtained by ignoring the "M-" method name prefix

4. If the evaluation in 3) was successful and the
request fulfilled, the server MUST respond as defined
section 5.1. A server MUST NOT fulfill a request
understanding and obeying all mandatory
declaration(s) in a request

A proxy that does not act as the ultimate recipient of a
extension declaration MUST NOT remove the extension declaration
the "M-" method name prefix when forwarding the message (see
5.1 for how to detect when a mandatory extension has been fulfilled).

A server receiving an HTTP/1.0 (or earlier versions of HTTP)
that includes a Connection header MUST, for each connection-token
this field, remove and ignore any header field(s) from the
with the same name as the connection-token

A server receiving a mandatory request including the "M-" method
prefix without any mandatory extension declarations to follow
return a 510 (Not Extended) response

Nielsen, et al. Experimental [Page 9]

RFC 2774 An HTTP Extension Framework February 2000

The "M-" prefix is reserved by this proposal and MUST NOT be used
other HTTP extensions

5.1 Fulfilling a Mandatory

A server MUST NOT claim to have fulfilled any mandatory
unless it understood and obeyed all the mandatory
declarations in the request. This section defines a mechanism
conveying this information to the client in such a way that
interoperates with existing HTTP applications and prevents
servers from giving the false impression that an extended request
fulfilled by responding with a 200 (Ok) response
understanding the method

If any end-to-end mandatory extension declarations were among
fulfilled extensions then the server MUST include an Ext
header field in the response. In order to avoid that the Ext
field inadvertently is cached in an HTTP/1.1 cache, the response
contain a no-cache cache-control directive. If the response
otherwise cachable, the no-cache cache-control directive SHOULD
limited to only affect the Ext header field

HTTP/1.1 200
Ext
Cache-Control: no-cache="Ext
...

If the mandatory request has been forwarded by an HTTP/1.0
intermediary proxy then this is indicated either directly in
Request-Line or by the presence of an HTTP/1.1 Via header field.
this case, the server MUST include an Expires header field with
date equal to or earlier than the value of the Date header field (
section 9 for a discussion on caching considerations):

HTTP/1.1 200
Date: Sun, 25 Oct 1998 08:12:31
Expires: Sun, 25 Oct 1998 08:12:31
Ext
Cache-Control: no-cache="Ext", max-age=3600
...

If any hop-by-hop mandatory extension declarations were among
fulfilled extensions then the server MUST include a C-Ext
header field in the response. The C-Ext header field MUST
protected by a Connection header field (see [5], section 14.10).

Nielsen, et al. Experimental [Page 10]

RFC 2774 An HTTP Extension Framework February 2000

HTTP/1.1 200
C-Ext
Connection: C-

Note, that the Ext and C-Ext header fields are not
exclusive; they can be both be present in a response when
mandatory request containing both hop-by-hop as well as end-to-
mandatory extension declarations

6. Mandatory HTTP

A server MUST NOT include mandatory extension declarations in an
response unless it is responding to a mandatory HTTP request
definition allowed for the mandatory response or the server has
a priori knowledge that the recipient can handle the
response. A server MAY include optional extension declarations
any HTTP response (see section 4).

If a client is the ultimate recipient of a mandatory HTTP
containing mandatory extension declarations that either the
does not understand or does not want to use, then it SHOULD
the complete response as if it were a 500 (Internal Server Error
response

7. 510 Not

The policy for accessing the resource has not been met in
request. The server should send back all the information
for the client to issue an extended request. It is outside the
of this specification to specify how the extensions inform
client

If the 510 response contains information about extensions that
not present in the initial request then the client MAY repeat
request if it has reason to believe it can fulfill the
policy by modifying the request according to the information
in the 510 response. Otherwise the client MAY present any
included in the 510 response to the user, since that entity
include relevant diagnostic information

8. Publishing an

While the protocol extension definition should be published at
address of the extension identifier, this specification does
require it. The only absolute requirement is that
identifiers MUST be globally unique identifiers, and that
names be used for distinct semantics

Nielsen, et al. Experimental [Page 11]

RFC 2774 An HTTP Extension Framework February 2000

Likewise, applications are not required to attempt
extension identifiers included in an extension declaration. The
absolute requirement is that an application MUST NOT
conformance with an extension that it does not recognize (
of whether it has tried to resolve the extension identifier or not).
This document does not provide any policy for how long or how
an application may attempt to resolve an extension identifier

The association between the extension identifier and
specification might be made by distributing a specification,
references the extension identifier

It is strongly recommended that the integrity and persistence of
extension identifier be maintained and kept unquestioned
the lifetime of the extension. Care should be taken not to
conflicting specifications that reference the same name. Even when
extension specification is made available at the address of the URI
care must be taken that the specification made available at
address does not change over time. One agent may associate
identifier with the old semantics, while another might associate
with the new semantics

The extension definition may be made available in
representations ranging

o a human-readable specification defining the extension
(see for example [7]),

o downloadable code which implements the semantics defined by
extension

o a formal interface description provided by the extension,

o a machine-readable specification defining the
semantics

For example, a software component that implements the
may reside at the same address as a human-readable
(distinguished by content negotiation). The human-
representation serves to document the extension and
deployment, while the software component would allow clients
servers to be dynamically extended

9. Caching

Use of extensions using the syntax defined by this document may
additional implications on the cachability of HTTP response
other than the ones described in section 5.1.

Nielsen, et al. Experimental [Page 12]

RFC 2774 An HTTP Extension Framework February 2000

The originator of an extended message should be able to
from the semantics of the extension whether or not the extension'
presence impacts the caching constraints of the response message.
an extension does require tighter constraints on the cachebility
the response, the originator MUST include the appropriate
of cache header fields (Cache-Control, Vary, Expires)
to the required level of constraints of the extended semantics

10. Security

Dynamic installation of extension facilities as described in
introduction involves software written by one party (the provider
the implementation) to be executed under the authority of
(the party operating the host software). This opens the host party
a variety of "Trojan horse" attacks by the provider, or a
third party that forges implementations under a provider's name. See
for example RFC2046 [4], section 4.5.2 for a discussion of
risks

11.

[1] Crocker, D., "Standard for the Format of ARPA Internet
Messages", STD 11, RFC 822, August 1982.

[2] Berners-Lee, T., Fielding, R. and H. Frystyk, "
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

[3] Bradner, S., "The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996.

[4] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
1996.

[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2068, January 1997.

[6] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.

[7] Masinter, L., "Hyper Text Coffee Pot Control
(HTCPCP/1.0)", RFC 2324, 1 April 1998.

[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

Nielsen, et al. Experimental [Page 13]

RFC 2774 An HTTP Extension Framework February 2000

[9] Nielsen, H., Connolly, D. and R. Khare, "PEP - an
mechanism for HTTP", Work in Progress

12.

Roy Fielding, Rohit Khare, Yaron Y. Goland, and Koen Holtman,
special recognition for their efforts in commenting in all phases
this specification. Also thanks to Josh Cohen, Ross Patterson,
Gettys, Larry Masinter, and to the people involved in PEP [9].

The contribution of World Wide Web Consortium (W3C) staff is part
the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity").

13. Authors'

Henrik Frystyk
Microsoft
1 Microsoft
Redmond, WA 98052,

EMail: frystyk@microsoft.

Paul J.
Microsoft
1 Microsoft
Redmond, WA 98052,

EMail: paulle@microsoft.

Scott
Agranat Systems, Inc
5 Clocktower Place, Suite 400
Maynard, MA 01754,

EMail: lawrence@agranat.

Nielsen, et al. Experimental [Page 14]

RFC 2774 An HTTP Extension Framework February 2000

14. Summary of Protocol

The following tables summarize the outcome of strength and scope
of the mandatory proposal of compliant and non-compliant HTTP
and origin servers. The summary is intended as a guide and index
the text, but is necessarily cryptic and incomplete. This
should never be used or referenced separately from the
specification

Table 1: Origin

Scope Hop-by-hop End-to-

Strength Optional Required Optional
(may) (must) (may) (must

Mandatory Standard 501 (Not Standard 501 (
unsupported processing Implemented) processing Implemented

Extension Standard 510 (Not Standard 510 (
unsupported processing Extended) processing Extended
Extension Extended Extended Extended
supported processing processing processing

Table 2: Proxy

Scope Hop-by-hop End-to-

Strength Optional Required Optional
(may) (must) (may) (must

Mandatory Strip 501 (Not Forward 501 (
unsupported extension Implemented) extension Implemented
or tunnel or

Extension Strip 510 (Not Forward
unsupported extension Extended) extension

Extension Extended Extended Extended
supported processing processing processing, processing
and strip and strip may strip may

Nielsen, et al. Experimental [Page 15]

RFC 2774 An HTTP Extension Framework February 2000

15.

The following examples show various scenarios using mandatory
HTTP/1.1 requests and responses. Information not essential
illustrating the examples is left out (referred to as "...")

15.1 User Agent to Origin

Table 3: User Agent directly to origin

Client issues a request M-GET /some-document HTTP/1.1
with one optional and Opt: "http://www.my.com/tracking
one mandatory extension Man: "http://www.foo.com/privacy
...

Origin server accepts HTTP/1.1 200
the mandatory extension Ext
but ignores the Cache-Control: max-age=120, no-cache="Ext
optional one. The ...
client can not see
this case that
optional extension
ignored

Table 4: Origin server with Vary header

Client issues a request M-GET /p/q HTTP/1.1
with one mandatory Man: "http://www.x.y/transform"; ns=16
extension 16-use-transform:
...

Origin server accepts HTTP/1.1 200
the mandatory but Ext
indicates that the Vary: Man, 16-use-
response varies on the Date: Sun, 25 Oct 1998 08:12:31
request extension Expires: Sun, 25 Oct 1998 08:12:31
declaration Cache-Control: no-cache="Ext", max-age=1000
...

Nielsen, et al. Experimental [Page 16]

RFC 2774 An HTTP Extension Framework February 2000

15.2 User Agent to Origin Server via HTTP/1.1

These two examples show how an extended request interacts with
HTTP/1.1 proxy

Table 5: HTTP/1.1 Proxy forwards extended

Client issues a request M-GET /some-document HTTP/1.1
with one optional and C-Opt: "http://www.meter.org/hits
one mandatory hop-by- C-Man: "http://www.copy.org/rights
hop extension Connection: C-Opt, C-
...

HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1
the request and takes Via: 1.1
out the connection ...

Origin server fails as HTTP/1.1 510 Not
the request does not ...
contain any
belonging to the M-

Table 6: HTTP/1.1 Proxy does not forward extended

Client issues a request M-GET /some-document HTTP/1.1
with one optional and C-Opt: "http://www.meter.org/hits
one mandatory hop-by- C-Man: "http://www.copy.org/rights
hop extension Connection: C-Opt, C-
...

HTTP/1.1 proxy refuses HTTP/1.1 501 Not
to forward the M-GET ...
method and returns

Origin server
sees the

Nielsen, et al. Experimental [Page 17]

RFC 2774 An HTTP Extension Framework February 2000

15.3 User Agent to Origin Server via HTTP/1.0

These two examples show how an extended request interacts with
HTTP/1.0 proxy in the message

Table 7: HTTP/1.0 Proxy forwards extended

Client issues a request M-GET /some-document HTTP/1.1
with one mandatory Man: "http://www.price.com/sale
extension ...

HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
the request as a Man: "http://www.price.com/sale
HTTP/1.0 request ...
without changing

Origin server accepts HTTP/1.1 200
declaration and returns Ext
a 200 response and an Date: Sun, 25 Oct 1998 08:12:31
extension Expires: Sun, 25 Oct 1998 08:12:31
acknowledgement. The Cache-Control: no-cache="Ext", max-age=600
response can be cached ...
by HTTP/1.1 caches
10 minutes

Table 8: HTTP/1.0 and HTTP/1.1 Proxy

Client issues request M-GET /some-document HTTP/1.1
with one mandatory and Man: "http://www.copy.org/rights
one hop-by-hop optional C-Opt: "http://www.ads.org/noads
extension Connection: C-
...

HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
request as HTTP/1.0 Man: "http://www.copy.org/rights
request without C-Opt: "http://www.ads.org/noads
changing the method and Connection: C-
without honoring the ...
Connection

HTTP/1.1 proxy deletes M-GET /some-document HTTP/1.1
(and ignores) optional Man: "http://www.copy.org/rights
extension and forwards C-Man: "http://www.ads.org/givemeads
the rest including a Connection: C-
via header field. It Via: 1.0
also add a hop-by-hop ...
mandatory

Nielsen, et al. Experimental [Page 18]

RFC 2774 An HTTP Extension Framework February 2000

Origin server accepts HTTP/1.1 200
both mandatory Ext
extensions. The C-
response is not Connection: C-
cachable by the Date: Sun, 25 Oct 1998 08:12:31
HTTP/1.0 cache but can Expires: Sun, 25 Oct 1998 08:12:31
be cached for 1 hour by Cache-Control: no-cache="Ext", max-age=3600
HTTP/1.1 caches. ...

HTTP/1.1 proxy removes HTTP/1.1 200
the hop-by-hop Ext
extension Date: Sun, 25 Oct 1998 08:12:31
acknowledgement and Expires: Sun, 25 Oct 1998 08:12:31
forwards the remainder Cache-Control: no-cache="Ext", max-age=3600
of the response. ...

Nielsen, et al. Experimental [Page 19]

RFC 2774 An HTTP Extension Framework February 2000

Full Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Nielsen, et al. Experimental [Page 20]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX