One document matched: draft-snell-http-batch-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc ipr="trust200811" category="std" docName="draft-snell-http-batch-00">
  <front>
    <title abbrev="HTTP BATCH">
      HTTP Multipart Batched Request Format
    </title>

    <author initials="J.M." surname="Snell" fullname="James M Snell">
      <organization>IBM</organization>
      <address>
        <postal>
          <street></street>
          <city>Hanford</city> <region>CA</region> <code>93230</code>
          <country></country>
        </postal>
        <phone></phone>
        <email>jasnell@us.ibm.com</email>
        <uri>http://www.ibm.com</uri>
      </address>
    </author>
    
    <date month="June" year="2009" />

    <area>Applications</area>
    <workgroup>Individual Submission</workgroup>
    <keyword>I-D</keyword>
    <keyword>http</keyword>
    <keyword>batch</keyword>
    <keyword>mime</keyword>
    <keyword>multipart</keyword>

    <abstract>
      <t>This document specifies a format for packaging multiple, independent 
      HTTP requests into a single multipart payload.</t>
    </abstract>

  </front>
  

  <middle>
    <section anchor="intro" title="Introduction">

      <t>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.</t>

      <t>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 <xref target="RFC2119" />.</t>

    </section>

    <section anchor="multipart-batch" title="The Multipart/Batch Content Type">
    
      <t>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.</t>
    
      <section anchor="type-parameter" title="The Type Parameter">
       
        <t>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.</t>
      
      </section>
    
      <section anchor="multipart-batch-example" title="Example">
        <t>The following illustrates an example Multipart/Batch message 
        containing two independent HTTP Request messages.</t>  
        <figure><artwork>
    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--
</artwork></figure>
      
      </section>
    
    </section>
        
    <section anchor="http-batch" title="Batching HTTP Requests">
    
      <t>As the example above illustrates, multiple, individual HTTP requests 
      and response messages can be collected into a single Multipart/Batch 
      package.</t>
      
      <t>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 <xref target="RFC2616" />.</t>
      
      <t>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.</t>      
      
      <t>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.</t>
      
      <t>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.</t> 
      
      <t>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.</t>
      
      <t>The example below contains a Batch Response for the Batch Request in
      Listing 1.</t>
        <figure><artwork>
    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--
</artwork></figure>
    
    </section>
        
    <section title="IANA Considerations">
      <section title="The 'Multipart/Batch' Content-Type">
    <t><figure><artwork>
    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
    </artwork></figure></t>
      </section>  
    </section>
    
    <section title="Security Considerations">
      <t>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.</t>
      
      <t>TODO: Need to expand the Security Considerations</t>
    </section>
  </middle>
  
  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc2616;
    </references>    
  </back>

</rfc>