Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Upgrading to TLS Within HTTP/1.1 (RFC2817)

IP.com Disclosure Number: IPCOM000003416D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 11 page(s) / 26K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Khare: AUTHOR [+2]

Abstract

This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 11% of the total text.

Network Working Group R. Khare

Request for Comments: 2817 4K Associates / UC Irvine

Updates: 2616 S. Lawrence

Category: Standards Track Agranat Systems, Inc.

May 2000

Upgrading to TLS Within HTTP/1.1

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

This memo explains how to use the Upgrade mechanism in HTTP/1.1 to

initiate Transport Layer Security (TLS) over an existing TCP

connection. This allows unsecured and secured HTTP traffic to share

the same well known port (in this case, http: at 80 rather than

https: at 443). It also enables "virtual hosting", so a single HTTP +

TLS server can disambiguate traffic intended for several hostnames at

a single IP address.

Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this

memo also documents the HTTP CONNECT method for establishing end-to-

end tunnels across HTTP proxies. Finally, this memo establishes new

IANA registries for public HTTP status codes, as well as public or

private Upgrade product tokens.

This memo does NOT affect the current definition of the 'https' URI

scheme, which already defines a separate namespace

(http://example.org/ and https://example.org/ are not equivalent).

Table of Contents

1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4

3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4

3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4

3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 4

4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5

4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5

4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5

5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6

5.1 Implications of Hop By Hop Upgrade . . ....