Individual Submission J. Snell Internet-Draft IBM Intended status: Standards Track June 8, 2009 Expires: December 10, 2009 HTTP Multipart Batched Request Format draft-snell-http-batch-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 10, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies a format for packaging multiple, independent HTTP requests into a single multipart payload. Snell Expires December 10, 2009 [Page 1] Internet-Draft HTTP BATCH June 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Multipart/Batch Content Type . . . . . . . . . . . . . . . 3 2.1. The Type Parameter . . . . . . . . . . . . . . . . . . . . 3 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Batching HTTP Requests . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4.1. The 'Multipart/Batch' Content-Type . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Snell Expires December 10, 2009 [Page 2] Internet-Draft HTTP BATCH June 2009 1. Introduction This specification defines a format for packaging multiple, independent HTTP requests into a single multipart MIME payload. The intent is to provide applications with a method of grouping sets of individual HTTP requests for processing as a unit and is designed to work around a number of limitations that currently exist in HTTP pipelining. That said, batching HTTP requests using the format defined here is not intended to replace pipelining. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2. The Multipart/Batch Content Type The Multipart/Batch content-type is a new subtype of MIME multipart message that indicates that message parts are to be considered as unrelated resources capable of being processed individually, and potentially in parallel, of one another. Each part in the batch MUST share a common Content-Type as specified by the Multipart/Batch content types Type parameter. Applications processing Multipart/ Batch parts MUST NOT assume that any relationship or dependency exists between the individual parts of the batch message. 2.1. The Type Parameter The type parameter MUST be specified and its value is the MIME media type of all the individual parts of the multipart message. Any message parts included in the multipart package that do not specify a Content-Type equivalent to that specified in the type parameter MUST be ignored. 2.2. Example The following illustrates an example Multipart/Batch message containing two independent HTTP Request messages. Snell Expires December 10, 2009 [Page 3] Internet-Draft HTTP BATCH June 2009 POST /example/application HTTP/1.1 Host: example.org Content-Type: multipart/batch; type="application/http;version=1.1"; boundary=batch Mime-Version: 1.0 --batch Content-Type: application/http;version=1.1 Content-Transfer-Encoding: binary Content-ID: POST /example/application HTTP/1.1 Host: example.org Content-Type: text/plain Content-Length: 3 Foo --batch Content-Type: application/http;version=1.1 Content-Transfer-Encoding: binary Content-ID: <226e35d0-34fa-11de-b418-0800200c9a66@example.org> PUT /example/application/resource HTTP/1.1 Host: example.org Content-Type: image/jpg Content-Length: 123456 {jpg image data} --batch-- 3. Batching HTTP Requests As the example above illustrates, multiple, individual HTTP requests and response messages can be collected into a single Multipart/Batch package. The type parameter of the Multipart/Batch content type and each part of the Multipart/Batch request MUST use the application/http Content- Type as specified by Section 19.1 of [RFC2616]. A Multipart/Batch of HTTP messages MUST contain either a set of HTTP requests or a set of HTTP responses but MUST NOT contain a mixture of requests and responses. This effectively creates two types of batched HTTP Multipart/Batch messages that will be referred to from this point on as HTTP Batch Requests and HTTP Batch Responses. Snell Expires December 10, 2009 [Page 4] Internet-Draft HTTP BATCH June 2009 A HTTP client user agent creates an HTTP Batch Request message containing one or more individual and independent HTTP requests and transmits that to the HTTP server as the payload of another HTTP request message. As illustrated in Listing 1. Each part MUST specify a Content-ID header specifying a reference identifier for the HTTP request message. The HTTP server receives the batch request message and processes each included request individually and independently of the others. The server can choose to process those messages in parallel to one another or in any order the server determines to be appropriate. Once the batched request messages have been processed, a single HTTP Batch Response message is created wherein each part contains the HTTP Response Messages. Each part of the response MUST contain an In- Reply-To header specifying the Content-ID of the HTTP request message that correlates to the response. To simplify client processing of the response, the ordering of response messages in the Batch Response SHOULD match the ordering of request messages in the Batch Request. However, client applications MUST NOT assume such ordering of responses and MUST use the Content-ID and In-Reply-To headers to correlate HTTP request and response messages in the Batch Requests and Batch Responses. The example below contains a Batch Response for the Batch Request in Listing 1. Snell Expires December 10, 2009 [Page 5] Internet-Draft HTTP BATCH June 2009 HTTP/1.1 200 OK Date: Wed, 29 Apr 2009 20:00:00 GMT Server: example.org Content-Type: multipart/batch; type="application/http;type=1.1"; boundary=batch Mime-Version: 1.0 --batch Content-Type: application/http;version=1.1 Content-Transfer-Encoding: binary In-Reply-To: HTTP/1.1 204 OK Date: Wed, 29 Apr 2009 20:00:00 GMT Server: example.org --batch Content-Type: application/http;version=1.1 Content-Transfer-Encoding: binary In-Reply-To: <226e35d0-34fa-11de-b418-0800200c9a66@example.org> HTTP/1.1 415 Unsupported Media Type Date: Wed, 29 Apr 2009 20:00:00 GMT Server: example.org --batch-- 4. IANA Considerations 4.1. The 'Multipart/Batch' Content-Type Media Type Name: Multipart Media Subtype Name: Batch Required Parameters: Type, a media type/subtype. Encoding considerations: N/A Security considerations: Depends on the batched content-type Published specification: This document Contact: James M Snell jasnell@us.ibm.com 877-511-5082 Snell Expires December 10, 2009 [Page 6] Internet-Draft HTTP BATCH June 2009 5. Security Considerations The security considerations for batched HTTP requests are identical to those of traditional, unbatched HTTP requests with one notable exception. Since a batch of HTTP requests is sent to an HTTP server as the payload of another request, a server processing batched requests must ensure that each is processed using an appropriate level of security. TODO: Need to expand the Security Considerations 6. Normative References [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. Author's Address James M Snell IBM Hanford, CA 93230 Phone: Email: jasnell@us.ibm.com URI: http://www.ibm.com Snell Expires December 10, 2009 [Page 7]