2004/id/draft-ietf-http-ses-ext-01.txt


HTTP Working Group                                Alexander Hopmann
INTERNET-DRAFT                                    ResNova Software, Inc.
<draft-ietf-http-ses-ext-01.txt>
Expires SIX MONTHS FROM--->                       February 21st, 1996

Persistent HTTP Connections


Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To learn the current status of any Internet-Draft, please check
   the "1id-abstracts.txt" listing contained in the Internet-
   Drafts Shadow Directories on ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   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@info.cern.ch> mailing list.

   This draft does not currently represent a consensus opinion of the
   HTTP Working Group.


Abstract

   HTTP was designed to be an extremely lightweight stateless protocol
   based on TCP. However actual implementation experience suggests that
   the overhead inherent in establishing a separate TCP connection for
   every request represents a significant performance problem. This
   proposal suggests an optional facility for HTTP version 1.1 which
   allows a client to create persistent connections with a server. This
   facility is also designed to work with proxy servers.


Table of Contents

   1.  Introduction
      1.1  Purpose
      1.2  Overall Operation
      1.3  Proxy Servers
      1.4   Sticky Headers
      1.5   Compatibility with HTTP/1.0
      1.6   Interaction With Security Protocols
      1.7   Practical Considerations
   2.  Examples
   3.  Security Considerations
   4.  Acknowledgments
   5.  References
   6.  Author's Address

1. Introduction


1.1  Purpose

   The HyperText Transfer Protocol's strongest point is its simplicity.
   The creators of HTTP [1] made it stateless in order to simplify
   server design and also make servers more efficient. However with
   the extraordinary success of the World Wide Web, HTTP servers
   are often overloaded. In addition, the use of inline images and other
   associated data often requires a client to make multiple requests of
   the same server in a short amount of time. HTTP usually runs on top
   of TCP which has many performance limitations for short-lived
   connections. Because of the way that HTTP works, these performance
   problems can become quite serious. An excellent analysis of these
   performance problems is available [2].

   This draft is being proposed as a component of HTTP version 1.1 [3].
   It is based on work being done by the HTTP working group of the IETF.

1.2  Overall Operation

   HTTP version 1.1 provides a new request and response header field
   called "Connection". This header field allows the client and server
   to specify options which should only exist over that particular
   connection and must not communicated by proxies over further
   connections. The connection header field may have multiple tokens
   separated by commas. HTTP version 1.1 proxies must parse this field
   and for every value in this field, remove a header field of the same
   name from the request.

   When a client is connecting directly to an origin server it should
   send the following:

   Connection: persist
   Persist: <origin-server-name>

   The value <origin-server-name> is either a domain name for the origin
   server in the IANA domain, or the IP address of the origin server in
   dot form (a.b.c.d). The origin server must verify that this name
   corresponds to it, or must not establish a persistent connection.

   If the server agrees to create a persistent connection it will
   respond with the same two header fields. Both the client and server
   must send these two header fields with every request and response for
   the duration of the persistent connection. If either the client or
   the server omits the Persist header that request becomes the last one
   for the connection. A server should not establish a persistent
   connection with a HTTP/1.0 client that uses the above form of the
   Persist header (See section 1.5 for more information on backwards
   compatibility with HTTP 1.0 clients).

   Once the client has received the first response from the server
   containing the "Persist" header field, it may pipeline multiple
   requests without waiting for the response from the previous ones. The
   server must send all of the responses in the same order that the
   requests were made.

   When using persistent connections both the client and the server must
   obey one of the following two rules in order to transmit an entity
   body:

   either

   a) Send a content-length field in the header with the exact number of
      bytes in the entity-body.

   or

   b) Send the message as Content-type: multipart/mixed (Or some other
      multipart content type), with a boundary marker. The end of the
      entity-body is specified by the exact ending of the ending
      boundary. Although RFC 1521 (MIME part 1) specifies that
      multipart/mixed messages may have an epilogue after the ending
      boundary, this epilogue must not be present for clients and
      servers using persistent connections.

1.3  Proxy Servers

   When a client is connecting to a proxy server it must send an
   expanded form of the persist header:

   Connection: persist
   persist: <proxy-name>

   The value <proxy-name> is either a domain name for the proxy server
   in the IANA domain, or the IP address of the proxy server in dot form
   (a.b.c.d).

   When the proxy server receives this request it must check the <proxy-
   name> value and make sure that it corresponds to itself. The server
   must choose some policy for determining if the proxy-name corresponds
   to itself. For example if the proxy-name is a domain name a server
   might do a domain-name lookup on that name and compare the returned
   IP address to its own. If the proxy-name does not correspond to the
   proxy, it must not establish a persistent connection.

   The proxy server must negotiate persistent connections separately
   with its clients and the origin servers (or other proxy servers) that
   it connects to. Each persistent connection applies to only one
   transport link.

   In no case should a proxy ever establish a persistent connection with
   an HTTP 1.0 client.

1.4  Sticky Headers

   In order to further maximize performance a client and a server may
   negotiate the use of sticky headers. Sticky headers can reduce the
   amount of redundant information that has to be transmitted with every
   request.

   The negotiation of the sticky headers option must take place on the
   first request of a persistent connection. The client may add the
   token "sticky" to the Connection header. If the server accepts the
   use of sticky headers, it responds with the same token in the
   Connection header of its response.

   When using sticky-headers, any values for the following header fields
   are remembered from request to request:

      accept, accept-charset, accept-language, accept-encoding,
      authorization, proxy-authorization, from, host, user-agent.

   When sticky-headers are being used, the server remembers the fields
   from the previous requests. If the client specifies a different value
   for a field in a request, the new value replaces the remembered
   value. Therefore the server acts as if the actual content of the
   fields of a request is the combination of the fields in the current
   request, and the remembered fields.

   If in any request the client does not include the "sticky" token in
   the connection header, the server must not use its stored values for
   the headers in interpreting the request.

   However, once the "sticky" option has been negotiated any subsequent
   request can contain the token. The server will then act as if the
   actual content of that new request is the combination of the fields
   in the current request and the fields of the previous request only.
   As a consequence, a server must record the values of the headers in
   each request, to be used in case the subsequent request specifies
   sticky headers.

1.5  Compatibility with HTTP/1.0

   Some clients and servers may wish to be compatible with some pervious
   implementations of persistent connections in HTTP version 1.0 clients
   and servers.

   When connecting to an origin server an HTTP client may send the
   following instead of that specified in section 1.2:

   Connection: keep-alive,persist
   Persist: <origin-server-name>
   Keep-alive:

   A client must not send the Keep-alive header field to a proxy server.

   An HTTP/1.0 server would then respond with the Keep-Alive header field
   and the client may proceed with a persistent connection.

   An HTTP/1.1 server may receive a keep-alive header field. It may then
   establish a persistent connection.

1.6  Interaction with Security Protocols

   It is expected that the Session extension will operate with both
   SHTTP [5] and SSL [6]. When used in conjunction with SHTTP the SHTTP
   request is prepared normally, persistent connection headers in the
   outermost request block (the one containing the "Secure" method).
   When used in conjunction with SSL a SSL session is started as normal
   and the first HTTP request made using SSL contains the persistent
   connection header.

1.7  Practical Considerations

   Servers will usually have some time-out value beyond which they will
   no longer maintain an inactive connection. Proxy servers might make
   this a higher value since it is likely that the client will be making
   more connections through the same server. The use of persistent
   connections places no requirements on the length of this time-out for
   either the client or the server.

   When a client or server wishes to time-out it should reset the
   transport connection.

2.  Examples

   The first example shows a client connecting to a server, requesting
   a session, and the server accepting.
   NOTE: In all examples the notation <CRLF> represents two octets, CR
   and LF.

   client: <opens connection to port 80>
   server: <accepts connection at port 80>

   client:
   GET / HTTP/1.1<CRLF>
   Accept: text/html<CRLF>
   Accept: image/jpeg<CRLF>
   Connection: persist<CRLF>
   Persist: www.resnova.com<CRLF>
   <CRLF>

   server:
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Content-Type: text/html<CRLF>
   Content-Length: 94<CRLF>
   Connection: persist<CRLF>
   Persist: www.resnova.com<CRLF>
   <CRLF>
   <html><head></head><body><CRLF>
   <h1>This is a message</h1><CRLF>
   <img src="myimg.jpg"><CRLF>
   </body></html><CRLF>

   client: (has read 94 octets of entity-body)
   GET /myimg.jpg HTTP/1.1<CRLF>
   <CRLF>

   server: (using same accept: values as the first request)
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Content-Type: image/jpeg<CRLF>
   Content-Length: 1024<CRLF>
   Connection: persist<CRLF>
   Persist: www.resnova.com<CRLF>
   <CRLF>
   <1024 octets of data here>

   client: (has read 1024 octets of entity-body)
   GET /somecgi.cgi HTTP/1.1<CRLF>
   Connection: persist<CRLF>
   Persist: www.resnova.com<CRLF>
   <CRLF>

   server: (Note that the server is running a CGI and doesn't know its
   expected size)

   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.1<CRLF>
   Content-Type: multipart/mixed; boundary="abcdefghijklmnop"<CRLF>
   Connection: persist<CRLF>
   Persist: www.resnova.com<CRLF>
   <CRLF>
   --abcdefghijklmnop<CRLF>
   Content-type: text/html<CRLF>
   <CRLF>
   <html><head></head><body><CRLF>
   <h1>This is a message</h1><CRLF>
   <img src="myimg.jpg"><CRLF>
   </body></html><CRLF>
   --abcdefghijklmnop--<CRLF>

   client: (has read the <CRLF> after the ending boundary
   <resets connection>

   server:
   <resets connection>


   The second example is identical to the first except that the server
   does not wish to establish a persistent connection.

   client:
   GET / HTTP/1.1<CRLF>
   Accept: text/html<CRLF>
   Accept: image/jpeg<CRLF>
   Connection: persist<CRLF>
   Persist: www.resnova.com<CRLF>
   <CRLF>

   server:
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Content-Type: text/html<CRLF>
   Content-Length: 94<CRLF>
   <CRLF>
   <html><head></head><body><CRLF>
   <h1>This is a message</h1><CRLF>
   <img src="myimg.jpg"><CRLF>
   </body></html><CRLF>

   <server closes connection>
   (client did not receive the persist header so it knows to identify
   the end of the body by the connection close).


   The third example demonstrates the use of sticky headers.

   client:
   <requesting first object, negotiating sticky headers>
   GET / HTTP/1.1<CRLF>
   Accept: text/html<CRLF>
   Accept-Language: en<CRLF>
   Connection: persist,sticky<CRLF>
   <CRLF>

   server:
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Connection: persist,sticky<CRLF>
   Content-Type: text/html<CRLF>
   Content-Length:94<CRLF>
   <CRLF>
   <94 bytes body data here>

   client:
   (client makes a request changing the Accept value but maintaining the
   value of the Accept-Language: field from the previous request)

   GET /myimg.jpg HTTP/1.1<CRLF>
   Accept: image/jpeg<CRLF>
   Connection: persist,sticky<CRLF>
   <CRLF>

   server:
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Connection: persist,sticky<CRLF>
   Content-Type: image/jpeg<CRLF>
   Content-Length:4000<CRLF>
   <CRLF>
   <4000 bytes body data here>

   client:
   (client makes a non-sticky request)
   GET /something.html HTTP/1.1<CRLF>
   Accept: text/html<CRLF>
   Accept-Language: x-pig-latin<CRLF>
   Connection: persist <CRLF>
   <CRLF>

   server:
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Connection: persist <CRLF>
   Content-Type: text/html<CRLF>
   Content-Length:106<CRLF>
   <CRLF>
   <106 bytes body data here>

   client:
   (client another sticky request)
   GET /more.html HTTP/1.1<CRLF>
   Connection: persist,sticky <CRLF>
   <CRLF>

   server:
   HTTP/1.1 200 OK<CRLF>
   MIME-Version: 1.0<CRLF>
   Connection: persist,sticky <CRLF>
   Content-Type: text/html<CRLF>
   Content-Length:164<CRLF>
   <CRLF>
   <164 bytes body data here>

3.  Security

   This HTTP extension has two indirect effects on security. Using
   sticky headers can reduce the performance penalty of authentication,
   since a client can send one authentication header and
   maintain that authentication for a period of time. On the other hand
   an attacker could theoretically intercept a previously initiated
   communication channel and substitute itself, gaining the
   authentication attributes of the client that initiated the
   communication. This latter attack could only work with the non-secure
   authentication methods anyway so it is not considered to be a serious
   concern by the author.

4. Acknowledgments

   The key contributors to the Persistent HTTP Connection effort include
   Roy T. Fielding (UCI), Alan Freier (Netscape), Jeff Mogul(DEC), Lou
   Montulli (Netscape), Paul Leach (Microsoft), Simon Spero (EIT), Andy
   Norman (HP), and Scott Powers (NCSA). Other contributors include
   Allan M. Schiffman (Terisa Systems), Greg Herlihy (ResNova Software),
   and Tim Berners-Lee (W3O).

5 References

   [1]  T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
        "HyperText Transfer Protocol -- HTTP/1.0"
        Internet-Draft (work in progress), UC Irvine,
        <URL:http://ds.internic.net/internet-drafts/
        draft-ietf-http-v10-spec-05.txt>, February 19, 1996.

   [2]  S. Spero. "Analysis of HTTP Performance Problems"
        <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>

   [3]  T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
        "HyperText Transfer Protocol -- HTTP/1.1"
        Internet-Draft (work in progress), UC Irvine,
        <URL:http://ds.internic.net/internet-drafts/
        draft-ietf-http-v11-spec-01.txt>, January 19, 1996.

   [4]  E. Rescorla, A. Schiffman
        "The Secure HyperText Transfer Protocol"
        Internet-Draft (work in progress)
        <URL:ftp://ietf.cnri.reston.va.us/internet-drafts/
        draft-ietf-wts-shttp-01.txt>, February, 1996.

   [5]  A. Freier, P Karlton, P. Kocher.
        "SSL Version 3.0"
        Internet- Draft (work in progress)
        <URL:ftp://ietf.cnri.reston.va.us/internet-drafts/
        draft-freier-ssl-version3-00.txt>, December, 1995.

6 Author's Address

   Alex Hopmann
   alex.hopmann@resnova.com
   President
   ResNova Software, Inc.
   5011 Argosy Dr. #13
   Huntington Beach, CA 92649


1
2	HTTP Working Group Alexander Hopmann
3	INTERNET-DRAFT ResNova Software, Inc.
4	<draft-ietf-http-ses-ext-01.txt>
5	Expires SIX MONTHS FROM---> February 21st, 1996
6
7	Persistent HTTP Connections
8
9
10
11	Status of this Memo
12
13	This document is an Internet-Draft. Internet-Drafts are working
14	documents of the Internet Engineering Task Force (IETF), its areas,
15	and its working groups. Note that other groups may also distribute
16	working documents as Internet-Drafts.
17
18	Internet-Drafts are draft documents valid for a maximum of six
19	months and may be updated, replaced, or obsoleted by other
20	documents at any time. It is inappropriate to use Internet-
21	Drafts as reference material or to cite them other than as
22	"work in progress."
23
24	To learn the current status of any Internet-Draft, please check
25	the "1id-abstracts.txt" listing contained in the Internet-
26	Drafts Shadow Directories on ds.internic.net (US East Coast),
27	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
28	munnari.oz.au (Pacific Rim).
29
30	Distribution of this document is unlimited. Please send comments
31	to the HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
32	Discussions of the working group are archived at
33	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
34	about HTTP and the applications which use HTTP should take place
35	on the <www-talk@info.cern.ch> mailing list.
36
37	This draft does not currently represent a consensus opinion of the
38	HTTP Working Group.
39
40
41	Abstract
42
43	HTTP was designed to be an extremely lightweight stateless protocol
44	based on TCP. However actual implementation experience suggests that
45	the overhead inherent in establishing a separate TCP connection for
46	every request represents a significant performance problem. This
47	proposal suggests an optional facility for HTTP version 1.1 which
48	allows a client to create persistent connections with a server. This
49	facility is also designed to work with proxy servers.
50
51
52	Table of Contents
53
54	1. Introduction
55	1.1 Purpose
56	1.2 Overall Operation
57	1.3 Proxy Servers
58	1.4 Sticky Headers
59	1.5 Compatibility with HTTP/1.0
60	1.6 Interaction With Security Protocols
61	1.7 Practical Considerations
62	2. Examples
63	3. Security Considerations
64	4. Acknowledgments
65	5. References
66	6. Author's Address
67
68	1. Introduction
69
70
71	1.1 Purpose
72
73	The HyperText Transfer Protocol's strongest point is its simplicity.
74	The creators of HTTP [1] made it stateless in order to simplify
75	server design and also make servers more efficient. However with
76	the extraordinary success of the World Wide Web, HTTP servers
77	are often overloaded. In addition, the use of inline images and other
78	associated data often requires a client to make multiple requests of
79	the same server in a short amount of time. HTTP usually runs on top
80	of TCP which has many performance limitations for short-lived
81	connections. Because of the way that HTTP works, these performance
82	problems can become quite serious. An excellent analysis of these
83	performance problems is available [2].
84
85	This draft is being proposed as a component of HTTP version 1.1 [3].
86	It is based on work being done by the HTTP working group of the IETF.
87
88	1.2 Overall Operation
89
90	HTTP version 1.1 provides a new request and response header field
91	called "Connection". This header field allows the client and server
92	to specify options which should only exist over that particular
93	connection and must not communicated by proxies over further
94	connections. The connection header field may have multiple tokens
95	separated by commas. HTTP version 1.1 proxies must parse this field
96	and for every value in this field, remove a header field of the same
97	name from the request.
98
99	When a client is connecting directly to an origin server it should
100	send the following:
101
102	Connection: persist
103	Persist: <origin-server-name>
104
105	The value <origin-server-name> is either a domain name for the origin
106	server in the IANA domain, or the IP address of the origin server in
107	dot form (a.b.c.d). The origin server must verify that this name
108	corresponds to it, or must not establish a persistent connection.
109
110	If the server agrees to create a persistent connection it will
111	respond with the same two header fields. Both the client and server
112	must send these two header fields with every request and response for
113	the duration of the persistent connection. If either the client or
114	the server omits the Persist header that request becomes the last one
115	for the connection. A server should not establish a persistent
116	connection with a HTTP/1.0 client that uses the above form of the
117	Persist header (See section 1.5 for more information on backwards
118	compatibility with HTTP 1.0 clients).
119
120	Once the client has received the first response from the server
121	containing the "Persist" header field, it may pipeline multiple
122	requests without waiting for the response from the previous ones. The
123	server must send all of the responses in the same order that the
124	requests were made.
125
126	When using persistent connections both the client and the server must
127	obey one of the following two rules in order to transmit an entity
128	body:
129
130	either
131
132	a) Send a content-length field in the header with the exact number of
133	bytes in the entity-body.
134
135	or
136
137	b) Send the message as Content-type: multipart/mixed (Or some other
138	multipart content type), with a boundary marker. The end of the
139	entity-body is specified by the exact ending of the ending
140	boundary. Although RFC 1521 (MIME part 1) specifies that
141	multipart/mixed messages may have an epilogue after the ending
142	boundary, this epilogue must not be present for clients and
143	servers using persistent connections.
144
145	1.3 Proxy Servers
146
147	When a client is connecting to a proxy server it must send an
148	expanded form of the persist header:
149
150	Connection: persist
151	persist: <proxy-name>
152
153	The value <proxy-name> is either a domain name for the proxy server
154	in the IANA domain, or the IP address of the proxy server in dot form
155	(a.b.c.d).
156
157	When the proxy server receives this request it must check the <proxy-
158	name> value and make sure that it corresponds to itself. The server
159	must choose some policy for determining if the proxy-name corresponds
160	to itself. For example if the proxy-name is a domain name a server
161	might do a domain-name lookup on that name and compare the returned
162	IP address to its own. If the proxy-name does not correspond to the
163	proxy, it must not establish a persistent connection.
164
165	The proxy server must negotiate persistent connections separately
166	with its clients and the origin servers (or other proxy servers) that
167	it connects to. Each persistent connection applies to only one
168	transport link.
169
170	In no case should a proxy ever establish a persistent connection with
171	an HTTP 1.0 client.
172
173	1.4 Sticky Headers
174
175	In order to further maximize performance a client and a server may
176	negotiate the use of sticky headers. Sticky headers can reduce the
177	amount of redundant information that has to be transmitted with every
178	request.
179
180	The negotiation of the sticky headers option must take place on the
181	first request of a persistent connection. The client may add the
182	token "sticky" to the Connection header. If the server accepts the
183	use of sticky headers, it responds with the same token in the
184	Connection header of its response.
185
186	When using sticky-headers, any values for the following header fields
187	are remembered from request to request:
188
189	accept, accept-charset, accept-language, accept-encoding,
190	authorization, proxy-authorization, from, host, user-agent.
191
192	When sticky-headers are being used, the server remembers the fields
193	from the previous requests. If the client specifies a different value
194	for a field in a request, the new value replaces the remembered
195	value. Therefore the server acts as if the actual content of the
196	fields of a request is the combination of the fields in the current
197	request, and the remembered fields.
198
199	If in any request the client does not include the "sticky" token in
200	the connection header, the server must not use its stored values for
201	the headers in interpreting the request.
202
203	However, once the "sticky" option has been negotiated any subsequent
204	request can contain the token. The server will then act as if the
205	actual content of that new request is the combination of the fields
206	in the current request and the fields of the previous request only.
207	As a consequence, a server must record the values of the headers in
208	each request, to be used in case the subsequent request specifies
209	sticky headers.
210
211	1.5 Compatibility with HTTP/1.0
212
213	Some clients and servers may wish to be compatible with some pervious
214	implementations of persistent connections in HTTP version 1.0 clients
215	and servers.
216
217	When connecting to an origin server an HTTP client may send the
218	following instead of that specified in section 1.2:
219
220	Connection: keep-alive,persist
221	Persist: <origin-server-name>
222	Keep-alive:
223
224	A client must not send the Keep-alive header field to a proxy server.
225
226	An HTTP/1.0 server would then respond with the Keep-Alive header field
227	and the client may proceed with a persistent connection.
228
229	An HTTP/1.1 server may receive a keep-alive header field. It may then
230	establish a persistent connection.
231
232	1.6 Interaction with Security Protocols
233
234	It is expected that the Session extension will operate with both
235	SHTTP [5] and SSL [6]. When used in conjunction with SHTTP the SHTTP
236	request is prepared normally, persistent connection headers in the
237	outermost request block (the one containing the "Secure" method).
238	When used in conjunction with SSL a SSL session is started as normal
239	and the first HTTP request made using SSL contains the persistent
240	connection header.
241
242	1.7 Practical Considerations
243
244	Servers will usually have some time-out value beyond which they will
245	no longer maintain an inactive connection. Proxy servers might make
246	this a higher value since it is likely that the client will be making
247	more connections through the same server. The use of persistent
248	connections places no requirements on the length of this time-out for
249	either the client or the server.
250
251	When a client or server wishes to time-out it should reset the
252	transport connection.
253
254	2. Examples
255
256	The first example shows a client connecting to a server, requesting
257	a session, and the server accepting.
258	NOTE: In all examples the notation <CRLF> represents two octets, CR
259	and LF.
260
261	client: <opens connection to port 80>
262	server: <accepts connection at port 80>
263
264	client:
265	GET / HTTP/1.1<CRLF>
266	Accept: text/html<CRLF>
267	Accept: image/jpeg<CRLF>
268	Connection: persist<CRLF>
269	Persist: www.resnova.com<CRLF>
270	<CRLF>
271
272	server:
273	HTTP/1.1 200 OK<CRLF>
274	MIME-Version: 1.0<CRLF>
275	Content-Type: text/html<CRLF>
276	Content-Length: 94<CRLF>
277	Connection: persist<CRLF>
278	Persist: www.resnova.com<CRLF>
279	<CRLF>
280	<html><head></head><body><CRLF>
281	<h1>This is a message</h1><CRLF>
282	<img src="myimg.jpg"><CRLF>
283	</body></html><CRLF>
284
285	client: (has read 94 octets of entity-body)
286	GET /myimg.jpg HTTP/1.1<CRLF>
287	<CRLF>
288
289	server: (using same accept: values as the first request)
290	HTTP/1.1 200 OK<CRLF>
291	MIME-Version: 1.0<CRLF>
292	Content-Type: image/jpeg<CRLF>
293	Content-Length: 1024<CRLF>
294	Connection: persist<CRLF>
295	Persist: www.resnova.com<CRLF>
296	<CRLF>
297	<1024 octets of data here>
298
299	client: (has read 1024 octets of entity-body)
300	GET /somecgi.cgi HTTP/1.1<CRLF>
301	Connection: persist<CRLF>
302	Persist: www.resnova.com<CRLF>
303	<CRLF>
304
305	server: (Note that the server is running a CGI and doesn't know its
306	expected size)
307
308	HTTP/1.1 200 OK<CRLF>
309	MIME-Version: 1.1<CRLF>
310	Content-Type: multipart/mixed; boundary="abcdefghijklmnop"<CRLF>
311	Connection: persist<CRLF>
312	Persist: www.resnova.com<CRLF>
313	<CRLF>
314	--abcdefghijklmnop<CRLF>
315	Content-type: text/html<CRLF>
316	<CRLF>
317	<html><head></head><body><CRLF>
318	<h1>This is a message</h1><CRLF>
319	<img src="myimg.jpg"><CRLF>
320	</body></html><CRLF>
321	--abcdefghijklmnop--<CRLF>
322
323	client: (has read the <CRLF> after the ending boundary
324	<resets connection>
325
326	server:
327	<resets connection>
328
329
330	The second example is identical to the first except that the server
331	does not wish to establish a persistent connection.
332
333	client:
334	GET / HTTP/1.1<CRLF>
335	Accept: text/html<CRLF>
336	Accept: image/jpeg<CRLF>
337	Connection: persist<CRLF>
338	Persist: www.resnova.com<CRLF>
339	<CRLF>
340
341	server:
342	HTTP/1.1 200 OK<CRLF>
343	MIME-Version: 1.0<CRLF>
344	Content-Type: text/html<CRLF>
345	Content-Length: 94<CRLF>
346	<CRLF>
347	<html><head></head><body><CRLF>
348	<h1>This is a message</h1><CRLF>
349	<img src="myimg.jpg"><CRLF>
350	</body></html><CRLF>
351
352	<server closes connection>
353	(client did not receive the persist header so it knows to identify
354	the end of the body by the connection close).
355
356
357	The third example demonstrates the use of sticky headers.
358
359	client:
360	<requesting first object, negotiating sticky headers>
361	GET / HTTP/1.1<CRLF>
362	Accept: text/html<CRLF>
363	Accept-Language: en<CRLF>
364	Connection: persist,sticky<CRLF>
365	<CRLF>
366
367	server:
368	HTTP/1.1 200 OK<CRLF>
369	MIME-Version: 1.0<CRLF>
370	Connection: persist,sticky<CRLF>
371	Content-Type: text/html<CRLF>
372	Content-Length:94<CRLF>
373	<CRLF>
374	<94 bytes body data here>
375
376	client:
377	(client makes a request changing the Accept value but maintaining the
378	value of the Accept-Language: field from the previous request)
379
380	GET /myimg.jpg HTTP/1.1<CRLF>
381	Accept: image/jpeg<CRLF>
382	Connection: persist,sticky<CRLF>
383	<CRLF>
384
385	server:
386	HTTP/1.1 200 OK<CRLF>
387	MIME-Version: 1.0<CRLF>
388	Connection: persist,sticky<CRLF>
389	Content-Type: image/jpeg<CRLF>
390	Content-Length:4000<CRLF>
391	<CRLF>
392	<4000 bytes body data here>
393
394	client:
395	(client makes a non-sticky request)
396	GET /something.html HTTP/1.1<CRLF>
397	Accept: text/html<CRLF>
398	Accept-Language: x-pig-latin<CRLF>
399	Connection: persist <CRLF>
400	<CRLF>
401
402	server:
403	HTTP/1.1 200 OK<CRLF>
404	MIME-Version: 1.0<CRLF>
405	Connection: persist <CRLF>
406	Content-Type: text/html<CRLF>
407	Content-Length:106<CRLF>
408	<CRLF>
409	<106 bytes body data here>
410
411	client:
412	(client another sticky request)
413	GET /more.html HTTP/1.1<CRLF>
414	Connection: persist,sticky <CRLF>
415	<CRLF>
416
417	server:
418	HTTP/1.1 200 OK<CRLF>
419	MIME-Version: 1.0<CRLF>
420	Connection: persist,sticky <CRLF>
421	Content-Type: text/html<CRLF>
422	Content-Length:164<CRLF>
423	<CRLF>
424	<164 bytes body data here>
425
426	3. Security
427
428	This HTTP extension has two indirect effects on security. Using
429	sticky headers can reduce the performance penalty of authentication,
430	since a client can send one authentication header and
431	maintain that authentication for a period of time. On the other hand
432	an attacker could theoretically intercept a previously initiated
433	communication channel and substitute itself, gaining the
434	authentication attributes of the client that initiated the
435	communication. This latter attack could only work with the non-secure
436	authentication methods anyway so it is not considered to be a serious
437	concern by the author.
438
439	4. Acknowledgments
440
441	The key contributors to the Persistent HTTP Connection effort include
442	Roy T. Fielding (UCI), Alan Freier (Netscape), Jeff Mogul(DEC), Lou
443	Montulli (Netscape), Paul Leach (Microsoft), Simon Spero (EIT), Andy
444	Norman (HP), and Scott Powers (NCSA). Other contributors include
445	Allan M. Schiffman (Terisa Systems), Greg Herlihy (ResNova Software),
446	and Tim Berners-Lee (W3O).
447
448	5 References
449
450	[1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
451	"HyperText Transfer Protocol -- HTTP/1.0"
452	Internet-Draft (work in progress), UC Irvine,
453	<URL:http://ds.internic.net/internet-drafts/
454	draft-ietf-http-v10-spec-05.txt>, February 19, 1996.
455
456	[2] S. Spero. "Analysis of HTTP Performance Problems"
457	<URL:http://sunsite.unc.edu/mdma-release/http-prob.html>
458
459	[3] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
460	"HyperText Transfer Protocol -- HTTP/1.1"
461	Internet-Draft (work in progress), UC Irvine,
462	<URL:http://ds.internic.net/internet-drafts/
463	draft-ietf-http-v11-spec-01.txt>, January 19, 1996.
464
465	[4] E. Rescorla, A. Schiffman
466	"The Secure HyperText Transfer Protocol"
467	Internet-Draft (work in progress)
468	<URL:ftp://ietf.cnri.reston.va.us/internet-drafts/
469	draft-ietf-wts-shttp-01.txt>, February, 1996.
470
471	[5] A. Freier, P Karlton, P. Kocher.
472	"SSL Version 3.0"
473	Internet- Draft (work in progress)
474	<URL:ftp://ietf.cnri.reston.va.us/internet-drafts/
475	draft-freier-ssl-version3-00.txt>, December, 1995.
476
477	6 Author's Address
478
479	Alex Hopmann
480	alex.hopmann@resnova.com
481	President
482	ResNova Software, Inc.
483	5011 Argosy Dr. #13
484	Huntington Beach, CA 92649
485
486
487