Internet DRAFT - draft-loreto-httpbis-proxy20
draft-loreto-httpbis-proxy20
HTTPBis Working Group S. Loreto
Internet-Draft R. Skog
Intended status: Informational H. Spaak
Expires: April 24, 2014 Ericsson
D. Druta
M. Hafeez
AT&T
October 21, 2013
2.0 Proxy in HTTP/2.0
draft-loreto-httpbis-proxy20-01
Abstract
This document defines and clarifies the role of proxies (aka
intermediaries) in HTTP 2.0. It aims to assure that HTTP 2.0
contains the same proxy features present in HTTP 1.1. It also
defines HTTP 2.0 proxies and advocates the importance and the
benefits that they can provide for HTTP 2.0. This document aims to
start the discussion within the HTTPBis wg.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Loreto, et al. Expires April 24, 2014 [Page 1]
Internet-Draft HTTP/2.0 Proxy October 2013
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Current Proxy usages . . . . . . . . . . . . . . . . . . . . . 4
4. HTTP 2.0 Proxy . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. HTTP 2.0 Proxy Features . . . . . . . . . . . . . . . . . . 5
4.2. 2.0 Proxy: discovery mechanisms . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Loreto, et al. Expires April 24, 2014 [Page 2]
Internet-Draft HTTP/2.0 Proxy October 2013
1. Introduction
Proxies (aka intermediaries) are an important part of existing HTTP
deployments; they both significantly help to support and improve the
scalability needs of the Web. Large enterprise deployments are
leveraging proxies in their architecture and home networking
solutions depend on intermediaries in order to connect to the
internet. These are just two examples of the use cases relying on
intermediaries and the current deployment scale will demand increased
compatibility with existing and future services. However till now
little effort has been spent to define and clarify the role
intermediaries play in HTTP 2.0.
This draft aims to assure that HTTP/2.0 contains the same proxy
features present in HTTP/1.1 [I-D.ietf-httpbis-p1-messaging],
[RFC2616] and [RFC2817].
This draft also advocates the importance and the benefits that
proxies can provide for HTTP/2.0 and aims to start a discussion on
this topic within the HTTPBis wg. Caching is not addressed in this
initial version of the document.
A Proxy is defined in HTTP/1.1 is a
"a message forwarding agent that is selected by the client,
usually via local configuration rules, to receive requests for
some type(s) of absolute URI and attempt to satisfy those requests
via translation through the HTTP interface."
A proxy acts as a server and a client for the purpose of making
requests on behalf of the client. The requests can be serviced
internally (i.e. if the Proxy also implement a cache) or by passing
them on to the origin server.
Proxies are often used to group an organization's HTTP requests
through a common intermediary for the sake of security, annotation
services, or shared caching.
Moreover Proxies can improve the Quality of Experience (QoE) in
particular scenarios, such as in a mobile network.
There are important Proxy uses cases currently used in HTTP 1.1 and
most likely they will be also important for 2.0 (see Section 3).
There are also Proxy use cases that will be 2.0 specific (see Section
4).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Loreto, et al. Expires April 24, 2014 [Page 3]
Internet-Draft HTTP/2.0 Proxy October 2013
document are to be interpreted as described in [RFC2119].
2. Terminology
HTTP1.1 [I-D.ietf-httpbis-p1-messaging] defines three form of
intermediaries:
Transforming proxy: Is designed and configured to modify request or
response messages in a semantically meaningful way. Such
transformation is presumed to be desired by the client that
selected the proxy.
Gateway (a.k.a., reverse proxy): is an intermediary that acts as an
origin server for the outbound connection, but translates received
requests and forwards them inbound to another server or servers.
Gateways also include proxies that transform requests from one
transport protocol to another, e.g. as in WAP (Wireless
Application Protocol) gateways which transformed WAP1 transport to
HTTP 1.1. For HTTP 2.0, which includes many of the same features
as WAP1 (e.g. header compression, body compression, tunneling of
multiple requests over a single connection/session, push, etc),
proxies may also need to provide such a transformation, e.g. to
enable a single client transport protocol connection (HTTP 2.0),
but transform that to an HTTP 1.1 connection for servers that do
not support HTTP 2.0.
Tunnel: acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary.
HTTP2.0 defines the following intermidiaries:
2.0 Proxy: an interposed entity the user-agent is informed about its
existence (by explicit configuration or other TBD mechanisms), and
that can be easily bypassed if the user-agent decide to do it.
3. Current Proxy usages
Among all the possible existing Proxy usages, there are some that
really improve the user QoE and also help the users while accessing
the Web.
Loreto, et al. Expires April 24, 2014 [Page 4]
Internet-Draft HTTP/2.0 Proxy October 2013
Network access control
Protocol Enhancement Proxy
Perform DNS requests on behalf of the user
The list above only enumerates some of the reliable Proxy usage that
would provide value also in 2.0.
4. HTTP 2.0 Proxy
In HTTP 2.0 an interposed proxy should always be discoverable by the
user-agent so that the user can consent it to stay or easily bypass
it.
The actual discovery mechanism is not discussed in this draft.
4.1. HTTP 2.0 Proxy Features
"2.0 Proxy" will provide in additions to the usages listed in Section
4 also other specific HTTP 2.0 usages. Some of them are listed
below.
Protocol version translation such as HTTP2.0 vs HTTP1.0/1.1 The HTTP
2.0 benefits will be valuable when it is used in mobile networks;
however not all sites on Internet will support 2.0 from day one.
The "2.0 Proxy" receives the HTTP 2.0 request by the user-agent
and sends a new request to the Origin Server. If the Origin
Server does not support HTTP 2.0 then the "2.0 Proxy" will
translate the HTTP 2.0 request to HTTP 1.1 request and will then
translate the HTTP 1.1 response to the HTTP 2.0 response.
Improve the HTTP/2.0 Flow Control management If both the user-agent
and the origin server support HTTP 2.0, the 2.0 proxy can improve
the Flow Control management as it is a hop-by-hop mechanism
defined to protect endpoints that are operating under resource
constraints.
Stream priority management A "2.0 Proxy" can improve the
transmission order for streams based on knowledge of the network
bandwidth-delay.
Push streams management A "2.0 Proxy" can adhere to network
condition and apply push streams management policy. As an example
a mobile user roaming can have policy saying not allowed push.
Loreto, et al. Expires April 24, 2014 [Page 5]
Internet-Draft HTTP/2.0 Proxy October 2013
4.2. 2.0 Proxy: discovery mechanisms
The end user, using HTTP 2.0, should become always aware of the
existence of any "2.0 Proxy" present in the network. The end user
may also be entitled to explicitly consent to use it or to bypass it,
although such entitlement may be limited for some applications or
service environments.
The actual discovery mechanism is not discussed in this draft. The
human factor implications of "proxy awareness" by the user are also
not discussed.
5. Acknowledgments
The authors wish to thank Thorsten Herber, Preeyaa Rawlani, Bryan
Sullivan for their invaluable comments.
6. References
6.1. Normative References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., Thomson, M., and A. Melnikov,
"Hypertext Transfer Protocol version 2.0",
draft-ietf-httpbis-http2-06 (work in progress),
August 2013.
[I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-24 (work in progress),
September 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Loreto, et al. Expires April 24, 2014 [Page 6]
Internet-Draft HTTP/2.0 Proxy October 2013
6.2. Informative References
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
Authors' Addresses
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Robert Skog
Ericsson
Sweeden
Email: robert.skog@ericsson.com
Hans Spaak
Ericsson
Sweeden
Email: hans.spaak@ericsson.com
Dan Druta
AT&T
Phone:
Email: dd5826@att.com
Loreto, et al. Expires April 24, 2014 [Page 7]
Internet-Draft HTTP/2.0 Proxy October 2013
Mohammad Hafeez
AT&T
Phone:
Email: mh2897@att.com
Loreto, et al. Expires April 24, 2014 [Page 8]
