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.

Table of Contents

1.  Introduction
2.  The Multipart/Batch Content Type
    2.1.  The Type Parameter
    2.2.  Example
3.  Batching HTTP Requests
4.  IANA Considerations
    4.1.  The 'Multipart/Batch' Content-Type
5.  Security Considerations
6.  Normative References
§  Author's Address

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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.

    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: <df536860-34f9-11de-b418-0800200c9a66@example.org>

    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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.).

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.

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.

    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: <df536860-34f9-11de-b418-0800200c9a66@example.org>

    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

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

Author's Address