to an https: URI. User agents that do not understand Upgrade:
Suppose that a 3xx code had been assigned for "Upgrade Required"; a
user agent that did not recognize it would treat it as 300. It would
then properly look for a "Location" header in the response and
attempt to repeat the request at the URL in that header field. Since
it did not know to Upgrade to incorporate the TLS layer, it would at
best fail again at the new URL.
7. IANA Considerations
IANA shall create registries for two name spaces, as described in BCP
o HTTP Status Codes
o HTTP Upgrade Tokens
7.1 HTTP Status Code Registry
The HTTP Status Code Registry defines the name space for the Status-
Code token in the Status line of an HTTP response. The initial
values for this name space are those specified by:
1. Draft Standard for HTTP/1.1 
2. Web Distributed Authoring and Versioning  [defines 420-424]
3. WebDAV Advanced Collections  (Work in Progress) [defines 425]
4. Section 6 [defines 426]
Values to be added to this name space SHOULD be subject to review in
the form of a standards track document within the IETF Applications
Area. Any such document SHOULD be traceable through statuses of
either 'Obsoletes' or 'Updates' to the Draft Standard for
7.2 HTTP Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for product
tokens used to identify protocols in the Upgrade HTTP header field.
Each registered token should be associated with one or a set of
specifications, and with contact information.
The Draft Standard for HTTP/1.1  specifies that these tokens obey
the production for 'product':
RFC 2817 HTTP Upgrade to TLS May 2000
product = token ["/" product-version]
product-version = token
Registrations should be allowed on a First Come First Served basis as
described in BCP 26 . These specifications need not be IETF
documents or be subject to IESG review, but should obey the following
1. A token, once registered, stays registered forever.
2. The registration MUST name a responsible party for the
3. The registration MUST name a point of contact.
4. The registration MAY name the documentation required for the
5. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them
available upon request.
6. The responsible party for the first registration of a "product"
token MUST approve later registrations of a "version" token
together with that "product" token before they can be registered.
7. If absolutely required, the IESG MAY reassign the responsibility
for a token. This will normally only be used in the case when a
responsible party cannot be contacted.
This specification defines the protocol token "TLS/1.0" as the
identifier for the protocol specified by The TLS Protocol .
It is NOT required that specifications for upgrade tokens be made
publicly available, but the contact information for the registration
8. Security Considerations
The potential for a man-in-the-middle attack (deleting the Upgrade
header) remains the same as current, mixed http/https practice:
o Removing the Upgrade header is similar to rewriting web pages to
change https:// links to http:// links.
o The risk is only present if the server is willing to vend such
information over both a secure and an insecure channel in the
o If the client knows for a fact that a server is TLS-compliant, it
can insist on it by only sending an Upgrade request with a no-op
method like OPTIONS.
o Finally, as the https: specification warns, "users should
carefully examine the certificate presented by the server to