/[hydra]/hydra/docs/rfc/rfc2817.txt
ViewVC logotype

Contents of /hydra/docs/rfc/rfc2817.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations)
Sun Sep 29 16:01:34 2002 UTC (21 years, 6 months ago) by nmav
Branch: MAIN
CVS Tags: hydra_0_1_6_without_hic, hydra_0_0_8, hydra_0_0_9, hydra_0_0_6, hydra_0_0_7, hydra_0_0_4, hydra_0_0_5, hydra_0_1_3, hydra_0_1_2, hydra_0_1_1, hydra_0_1_0, hydra_0_1_7, hydra_0_1_6, hydra_0_1_4, hydra_0_1_8, hydra_0_0_10, HEAD
Branch point for: hydra_0_1_0_patches
File MIME type: text/plain
Added RFCs and drafts about HTTP

1
2
3
4
5
6
7 Network Working Group R. Khare
8 Request for Comments: 2817 4K Associates / UC Irvine
9 Updates: 2616 S. Lawrence
10 Category: Standards Track Agranat Systems, Inc.
11 May 2000
12
13
14 Upgrading to TLS Within HTTP/1.1
15
16 Status of this Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26 Copyright (C) The Internet Society (2000). All Rights Reserved.
27
28 Abstract
29
30 This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
31 initiate Transport Layer Security (TLS) over an existing TCP
32 connection. This allows unsecured and secured HTTP traffic to share
33 the same well known port (in this case, http: at 80 rather than
34 https: at 443). It also enables "virtual hosting", so a single HTTP +
35 TLS server can disambiguate traffic intended for several hostnames at
36 a single IP address.
37
38 Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this
39 memo also documents the HTTP CONNECT method for establishing end-to-
40 end tunnels across HTTP proxies. Finally, this memo establishes new
41 IANA registries for public HTTP status codes, as well as public or
42 private Upgrade product tokens.
43
44 This memo does NOT affect the current definition of the 'https' URI
45 scheme, which already defines a separate namespace
46 (http://example.org/ and https://example.org/ are not equivalent).
47
48
49
50
51
52
53
54
55
56
57
58 Khare & Lawrence Standards Track [Page 1]
59
60 RFC 2817 HTTP Upgrade to TLS May 2000
61
62
63 Table of Contents
64
65 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
68 3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4
69 3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4
70 3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4
71 3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 4
72 4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5
73 4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5
74 4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5
75 5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6
76 5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6
77 5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6
78 5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7
79 6. Rationale for the use of a 4xx (client error) Status Code . . 7
80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
81 7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8
82 7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8
83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
84 8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
85 8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10
86 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
88 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
89 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
90
91 1. Motivation
92
93 The historical practice of deploying HTTP over SSL3 [3] has
94 distinguished the combination from HTTP alone by a unique URI scheme
95 and the TCP port number. The scheme 'http' meant the HTTP protocol
96 alone on port 80, while 'https' meant the HTTP protocol over SSL on
97 port 443. Parallel well-known port numbers have similarly been
98 requested -- and in some cases, granted -- to distinguish between
99 secured and unsecured use of other application protocols (e.g.
100 snews, ftps). This approach effectively halves the number of
101 available well known ports.
102
103 At the Washington DC IETF meeting in December 1997, the Applications
104 Area Directors and the IESG reaffirmed that the practice of issuing
105 parallel "secure" port numbers should be deprecated. The HTTP/1.1
106 Upgrade mechanism can apply Transport Layer Security [6] to an open
107 HTTP connection.
108
109
110
111
112
113
114 Khare & Lawrence Standards Track [Page 2]
115
116 RFC 2817 HTTP Upgrade to TLS May 2000
117
118
119 In the nearly two years since, there has been broad acceptance of the
120 concept behind this proposal, but little interest in implementing
121 alternatives to port 443 for generic Web browsing. In fact, nothing
122 in this memo affects the current interpretation of https: URIs.
123 However, new application protocols built atop HTTP, such as the
124 Internet Printing Protocol [7], call for just such a mechanism in
125 order to move ahead in the IETF standards process.
126
127 The Upgrade mechanism also solves the "virtual hosting" problem.
128 Rather than allocating multiple IP addresses to a single host, an
129 HTTP/1.1 server will use the Host: header to disambiguate the
130 intended web service. As HTTP/1.1 usage has grown more prevalent,
131 more ISPs are offering name-based virtual hosting, thus delaying IP
132 address space exhaustion.
133
134 TLS (and SSL) have been hobbled by the same limitation as earlier
135 versions of HTTP: the initial handshake does not specify the intended
136 hostname, relying exclusively on the IP address. Using a cleartext
137 HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
138 certificates based on the initial Host: header -- will allow ISPs to
139 provide secure name-based virtual hosting as well.
140
141 2. Introduction
142
143 TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-
144 to-end connection, optionally including strong mutual authentication,
145 using a variety of cryptosystems. Initially, a handshake phase uses
146 three subprotocols to set up a record layer, authenticate endpoints,
147 set parameters, as well as report errors. Then, there is an ongoing
148 layered record protocol that handles encryption, compression, and
149 reassembly for the remainder of the connection. The latter is
150 intended to be completely transparent. For example, there is no
151 dependency between TLS's record markers and or certificates and
152 HTTP/1.1's chunked encoding or authentication.
153
154 Either the client or server can use the HTTP/1.1 [1] Upgrade
155 mechanism (Section 14.42) to indicate that a TLS-secured connection
156 is desired or necessary. This memo defines the "TLS/1.0" Upgrade
157 token, and a new HTTP Status Code, "426 Upgrade Required".
158
159 Section 3 and Section 4 describe the operation of a directly
160 connected client and server. Intermediate proxies must establish an
161 end-to-end tunnel before applying those operations, as explained in
162 Section 5.
163
164
165
166
167
168
169
170 Khare & Lawrence Standards Track [Page 3]
171
172 RFC 2817 HTTP Upgrade to TLS May 2000
173
174
175 2.1 Requirements Terminology
176
177 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
178 "MAY" that appear in this document are to be interpreted as described
179 in RFC 2119 [11].
180
181 3. Client Requested Upgrade to HTTP over TLS
182
183 When the client sends an HTTP/1.1 request with an Upgrade header
184 field containing the token "TLS/1.0", it is requesting the server to
185 complete the current HTTP/1.1 request after switching to TLS/1.0.
186
187 3.1 Optional Upgrade
188
189 A client MAY offer to switch to secured operation during any clear
190 HTTP request when an unsecured response would be acceptable:
191
192 GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
193 Host: example.bank.com
194 Upgrade: TLS/1.0
195 Connection: Upgrade
196
197 In this case, the server MAY respond to the clear HTTP operation
198 normally, OR switch to secured operation (as detailed in the next
199 section).
200
201 Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
202 supplied within a Connection header field (section 14.10) whenever
203 Upgrade is present in an HTTP/1.1 message".
204
205 3.2 Mandatory Upgrade
206
207 If an unsecured response would be unacceptable, a client MUST send an
208 OPTIONS request first to complete the switch to TLS/1.0 (if
209 possible).
210
211 OPTIONS * HTTP/1.1
212 Host: example.bank.com
213 Upgrade: TLS/1.0
214 Connection: Upgrade
215
216 3.3 Server Acceptance of Upgrade Request
217
218 As specified in HTTP/1.1 [1], if the server is prepared to initiate
219 the TLS handshake, it MUST send the intermediate "101 Switching
220 Protocol" and MUST include an Upgrade response header specifying the
221 tokens of the protocol stack it is switching to:
222
223
224
225
226 Khare & Lawrence Standards Track [Page 4]
227
228 RFC 2817 HTTP Upgrade to TLS May 2000
229
230
231 HTTP/1.1 101 Switching Protocols
232 Upgrade: TLS/1.0, HTTP/1.1
233 Connection: Upgrade
234
235 Note that the protocol tokens listed in the Upgrade header of a 101
236 Switching Protocols response specify an ordered 'bottom-up' stack.
237
238 As specified in HTTP/1.1 [1], Section 10.1.2: "The server will
239 switch protocols to those defined by the response's Upgrade header
240 field immediately after the empty line which terminates the 101
241 response".
242
243 Once the TLS handshake completes successfully, the server MUST
244 continue with the response to the original request. Any TLS handshake
245 failure MUST lead to disconnection, per the TLS error alert
246 specification.
247
248 4. Server Requested Upgrade to HTTP over TLS
249
250 The Upgrade response header field advertises possible protocol
251 upgrades a server MAY accept. In conjunction with the "426 Upgrade
252 Required" status code, a server can advertise the exact protocol
253 upgrade(s) that a client MUST accept to complete the request.
254
255 4.1 Optional Advertisement
256
257 As specified in HTTP/1.1 [1], the server MAY include an Upgrade
258 header in any response other than 101 or 426 to indicate a
259 willingness to switch to any (combination) of the protocols listed.
260
261 4.2 Mandatory Advertisement
262
263 A server MAY indicate that a client request can not be completed
264 without TLS using the "426 Upgrade Required" status code, which MUST
265 include an an Upgrade header field specifying the token of the
266 required TLS version.
267
268 HTTP/1.1 426 Upgrade Required
269 Upgrade: TLS/1.0, HTTP/1.1
270 Connection: Upgrade
271
272 The server SHOULD include a message body in the 426 response which
273 indicates in human readable form the reason for the error and
274 describes any alternative courses which may be available to the user.
275
276 Note that even if a client is willing to use TLS, it must use the
277 operations in Section 3 to proceed; the TLS handshake cannot begin
278 immediately after the 426 response.
279
280
281
282 Khare & Lawrence Standards Track [Page 5]
283
284 RFC 2817 HTTP Upgrade to TLS May 2000
285
286
287 5. Upgrade across Proxies
288
289 As a hop-by-hop header, Upgrade is negotiated between each pair of
290 HTTP counterparties. If a User Agent sends a request with an Upgrade
291 header to a proxy, it is requesting a change to the protocol between
292 itself and the proxy, not an end-to-end change.
293
294 Since TLS, in particular, requires end-to-end connectivity to provide
295 authentication and prevent man-in-the-middle attacks, this memo
296 specifies the CONNECT method to establish a tunnel across proxies.
297
298 Once a tunnel is established, any of the operations in Section 3 can
299 be used to establish a TLS connection.
300
301 5.1 Implications of Hop By Hop Upgrade
302
303 If an origin server receives an Upgrade header from a proxy and
304 responds with a 101 Switching Protocols response, it is changing the
305 protocol only on the connection between the proxy and itself.
306 Similarly, a proxy might return a 101 response to its client to
307 change the protocol on that connection independently of the protocols
308 it is using to communicate toward the origin server.
309
310 These scenarios also complicate diagnosis of a 426 response. Since
311 Upgrade is a hop-by-hop header, a proxy that does not recognize 426
312 might remove the accompanying Upgrade header and prevent the client
313 from determining the required protocol switch. If a client receives
314 a 426 status without an accompanying Upgrade header, it will need to
315 request an end to end tunnel connection as described in Section 5.2
316 and repeat the request in order to obtain the required upgrade
317 information.
318
319 This hop-by-hop definition of Upgrade was a deliberate choice. It
320 allows for incremental deployment on either side of proxies, and for
321 optimized protocols between cascaded proxies without the knowledge of
322 the parties that are not a part of the change.
323
324 5.2 Requesting a Tunnel with CONNECT
325
326 A CONNECT method requests that a proxy establish a tunnel connection
327 on its behalf. The Request-URI portion of the Request-Line is always
328 an 'authority' as defined by URI Generic Syntax [2], which is to say
329 the host name and port number destination of the requested connection
330 separated by a colon:
331
332 CONNECT server.example.com:80 HTTP/1.1
333 Host: server.example.com:80
334
335
336
337
338 Khare & Lawrence Standards Track [Page 6]
339
340 RFC 2817 HTTP Upgrade to TLS May 2000
341
342
343 Other HTTP mechanisms can be used normally with the CONNECT method --
344 except end-to-end protocol Upgrade requests, of course, since the
345 tunnel must be established first.
346
347 For example, proxy authentication might be used to establish the
348 authority to create a tunnel:
349
350 CONNECT server.example.com:80 HTTP/1.1
351 Host: server.example.com:80
352 Proxy-Authorization: basic aGVsbG86d29ybGQ=
353
354 Like any other pipelined HTTP/1.1 request, data to be tunneled may be
355 sent immediately after the blank line. The usual caveats also apply:
356 data may be discarded if the eventual response is negative, and the
357 connection may be reset with no response if more than one TCP segment
358 is outstanding.
359
360 5.3 Establishing a Tunnel with CONNECT
361
362 Any successful (2xx) response to a CONNECT request indicates that the
363 proxy has established a connection to the requested host and port,
364 and has switched to tunneling the current connection to that server
365 connection.
366
367 It may be the case that the proxy itself can only reach the requested
368 origin server through another proxy. In this case, the first proxy
369 SHOULD make a CONNECT request of that next proxy, requesting a tunnel
370 to the authority. A proxy MUST NOT respond with any 2xx status code
371 unless it has either a direct or tunnel connection established to the
372 authority.
373
374 An origin server which receives a CONNECT request for itself MAY
375 respond with a 2xx status code to indicate that a connection is
376 established.
377
378 If at any point either one of the peers gets disconnected, any
379 outstanding data that came from that peer will be passed to the other
380 one, and after that also the other connection will be terminated by
381 the proxy. If there is outstanding data to that peer undelivered,
382 that data will be discarded.
383
384 6. Rationale for the use of a 4xx (client error) Status Code
385
386 Reliable, interoperable negotiation of Upgrade features requires an
387 unambiguous failure signal. The 426 Upgrade Required status code
388 allows a server to definitively state the precise protocol extensions
389 a given resource must be served with.
390
391
392
393
394 Khare & Lawrence Standards Track [Page 7]
395
396 RFC 2817 HTTP Upgrade to TLS May 2000
397
398
399 It might at first appear that the response should have been some form
400 of redirection (a 3xx code), by analogy to an old-style redirection
401 to an https: URI. User agents that do not understand Upgrade:
402 preclude this.
403
404 Suppose that a 3xx code had been assigned for "Upgrade Required"; a
405 user agent that did not recognize it would treat it as 300. It would
406 then properly look for a "Location" header in the response and
407 attempt to repeat the request at the URL in that header field. Since
408 it did not know to Upgrade to incorporate the TLS layer, it would at
409 best fail again at the new URL.
410
411 7. IANA Considerations
412
413 IANA shall create registries for two name spaces, as described in BCP
414 26 [10]:
415
416 o HTTP Status Codes
417 o HTTP Upgrade Tokens
418
419 7.1 HTTP Status Code Registry
420
421 The HTTP Status Code Registry defines the name space for the Status-
422 Code token in the Status line of an HTTP response. The initial
423 values for this name space are those specified by:
424
425 1. Draft Standard for HTTP/1.1 [1]
426 2. Web Distributed Authoring and Versioning [4] [defines 420-424]
427 3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
428 4. Section 6 [defines 426]
429
430 Values to be added to this name space SHOULD be subject to review in
431 the form of a standards track document within the IETF Applications
432 Area. Any such document SHOULD be traceable through statuses of
433 either 'Obsoletes' or 'Updates' to the Draft Standard for
434 HTTP/1.1 [1].
435
436 7.2 HTTP Upgrade Token Registry
437
438 The HTTP Upgrade Token Registry defines the name space for product
439 tokens used to identify protocols in the Upgrade HTTP header field.
440 Each registered token should be associated with one or a set of
441 specifications, and with contact information.
442
443 The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
444 the production for 'product':
445
446
447
448
449
450 Khare & Lawrence Standards Track [Page 8]
451
452 RFC 2817 HTTP Upgrade to TLS May 2000
453
454
455 product = token ["/" product-version]
456 product-version = token
457
458 Registrations should be allowed on a First Come First Served basis as
459 described in BCP 26 [10]. These specifications need not be IETF
460 documents or be subject to IESG review, but should obey the following
461 rules:
462
463 1. A token, once registered, stays registered forever.
464 2. The registration MUST name a responsible party for the
465 registration.
466 3. The registration MUST name a point of contact.
467 4. The registration MAY name the documentation required for the
468 token.
469 5. The responsible party MAY change the registration at any time.
470 The IANA will keep a record of all such changes, and make them
471 available upon request.
472 6. The responsible party for the first registration of a "product"
473 token MUST approve later registrations of a "version" token
474 together with that "product" token before they can be registered.
475 7. If absolutely required, the IESG MAY reassign the responsibility
476 for a token. This will normally only be used in the case when a
477 responsible party cannot be contacted.
478
479 This specification defines the protocol token "TLS/1.0" as the
480 identifier for the protocol specified by The TLS Protocol [6].
481
482 It is NOT required that specifications for upgrade tokens be made
483 publicly available, but the contact information for the registration
484 SHOULD be.
485
486 8. Security Considerations
487
488 The potential for a man-in-the-middle attack (deleting the Upgrade
489 header) remains the same as current, mixed http/https practice:
490
491 o Removing the Upgrade header is similar to rewriting web pages to
492 change https:// links to http:// links.
493 o The risk is only present if the server is willing to vend such
494 information over both a secure and an insecure channel in the
495 first place.
496 o If the client knows for a fact that a server is TLS-compliant, it
497 can insist on it by only sending an Upgrade request with a no-op
498 method like OPTIONS.
499 o Finally, as the https: specification warns, "users should
500 carefully examine the certificate presented by the server to
501 determine if it meets their expectations".
502
503
504
505
506 Khare & Lawrence Standards Track [Page 9]
507
508 RFC 2817 HTTP Upgrade to TLS May 2000
509
510
511 Furthermore, for clients that do not explicitly try to invoke TLS,
512 servers can use the Upgrade header in any response other than 101 or
513 426 to advertise TLS compliance. Since TLS compliance should be
514 considered a feature of the server and not the resource at hand, it
515 should be sufficient to send it once, and let clients cache that
516 fact.
517
518 8.1 Implications for the https: URI Scheme
519
520 While nothing in this memo affects the definition of the 'https' URI
521 scheme, widespread adoption of this mechanism for HyperText content
522 could use 'http' to identify both secure and non-secure resources.
523
524 The choice of what security characteristics are required on the
525 connection is left to the client and server. This allows either
526 party to use any information available in making this determination.
527 For example, user agents may rely on user preference settings or
528 information about the security of the network such as 'TLS required
529 on all POST operations not on my local net', or servers may apply
530 resource access rules such as 'the FORM on this page must be served
531 and submitted using TLS'.
532
533 8.2 Security Considerations for CONNECT
534
535 A generic TCP tunnel is fraught with security risks. First, such
536 authorization should be limited to a small number of known ports.
537 The Upgrade: mechanism defined here only requires onward tunneling at
538 port 80. Second, since tunneled data is opaque to the proxy, there
539 are additional risks to tunneling to other well-known or reserved
540 ports. A putative HTTP client CONNECTing to port 25 could relay spam
541 via SMTP, for example.
542
543 References
544
545 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
546 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
547 HTTP/1.1", RFC 2616, June 1999.
548
549 [2] Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
550 Syntax", RFC 2396, August 1998.
551
552 [3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
553
554 [4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
555 "Web Distributed Authoring and Versioning", RFC 2518, February
556 1999.
557
558
559
560
561
562 Khare & Lawrence Standards Track [Page 10]
563
564 RFC 2817 HTTP Upgrade to TLS May 2000
565
566
567 [5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
568 Protocol", Work In Progress.
569
570 [6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
571 1999.
572
573 [7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
574 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
575 1999.
576
577 [8] Luotonen, A., "Tunneling TCP based protocols through Web proxy
578 servers", Work In Progress. (Also available in: Luotonen, Ari.
579 Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
580
581 [9] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
582 1999.
583
584 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
585 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
586
587 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
588 Levels", BCP 14, RFC 2119, March 1997.
589
590 Authors' Addresses
591
592 Rohit Khare
593 4K Associates / UC Irvine
594 3207 Palo Verde
595 Irvine, CA 92612
596 US
597
598 Phone: +1 626 806 7574
599 EMail: rohit@4K-associates.com
600 URI: http://www.4K-associates.com/
601
602
603 Scott Lawrence
604 Agranat Systems, Inc.
605 5 Clocktower Place
606 Suite 400
607 Maynard, MA 01754
608 US
609
610 Phone: +1 978 461 0888
611 EMail: lawrence@agranat.com
612 URI: http://www.agranat.com/
613
614
615
616
617
618 Khare & Lawrence Standards Track [Page 11]
619
620 RFC 2817 HTTP Upgrade to TLS May 2000
621
622
623 Appendix A. Acknowledgments
624
625 The CONNECT method was originally described in a Work in Progress
626 titled, "Tunneling TCP based protocols through Web proxy servers",
627 [8] by Ari Luotonen of Netscape Communications Corporation. It was
628 widely implemented by HTTP proxies, but was never made a part of any
629 IETF Standards Track document. The method name CONNECT was reserved,
630 but not defined in [1].
631
632 The definition provided here is derived directly from that earlier
633 memo, with some editorial changes and conformance to the stylistic
634 conventions since established in other HTTP specifications.
635
636 Additional Thanks to:
637
638 o Paul Hoffman for his work on the STARTTLS command extension for
639 ESMTP.
640 o Roy Fielding for assistance with the rationale behind Upgrade:
641 and its interaction with OPTIONS.
642 o Eric Rescorla for his work on standardizing the existing https:
643 practice to compare with.
644 o Marshall Rose, for the xml2rfc document type description and tools
645 [9].
646 o Jim Whitehead, for sorting out the current range of available HTTP
647 status codes.
648 o Henrik Frystyk Nielsen, whose work on the Mandatory extension
649 mechanism pointed out a hop-by-hop Upgrade still requires
650 tunneling.
651 o Harald Alvestrand for improvements to the token registration
652 rules.
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674 Khare & Lawrence Standards Track [Page 12]
675
676 RFC 2817 HTTP Upgrade to TLS May 2000
677
678
679 Full Copyright Statement
680
681 Copyright (C) The Internet Society (2000). All Rights Reserved.
682
683 This document and translations of it may be copied and furnished to
684 others, and derivative works that comment on or otherwise explain it
685 or assist in its implementation may be prepared, copied, published
686 and distributed, in whole or in part, without restriction of any
687 kind, provided that the above copyright notice and this paragraph are
688 included on all such copies and derivative works. However, this
689 document itself may not be modified in any way, such as by removing
690 the copyright notice or references to the Internet Society or other
691 Internet organizations, except as needed for the purpose of
692 developing Internet standards in which case the procedures for
693 copyrights defined in the Internet Standards process must be
694 followed, or as required to translate it into languages other than
695 English.
696
697 The limited permissions granted above are perpetual and will not be
698 revoked by the Internet Society or its successors or assigns.
699
700 This document and the information contained herein is provided on an
701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
706
707 Acknowledgement
708
709 Funding for the RFC Editor function is currently provided by the
710 Internet Society.
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730 Khare & Lawrence Standards Track [Page 13]
731

webmaster@linux.gr
ViewVC Help
Powered by ViewVC 1.1.26