One document matched: draft-snell-http-batch-00.txt
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: <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].
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: <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
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:48 |