[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Individual Submission                                    T. Harding, Ed.
Internet-Draft                                                     Axway
Intended status: Informational                          January 26, 2011
Expires: July 30, 2011


                  AS2 Restart for Very Large Messages
                      draft-harding-as2-restart-02

Abstract

   AS2 Restart provides a method for AS2 clients and servers to restart
   payload transfers from the point of failure without requiring the
   entire document to be resent.

Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

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 July 30, 2011.

Copyright Notice

   Copyright (c) 2011 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
   carefully, as they describe your rights and restrictions with respect



Harding                   Expires July 30, 2011                 [Page 1]


Internet-Draft              Abbreviated Title               January 2011


   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.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Transfer ID . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  HEAD Query  . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.3.  POST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Important Considerations  . . . . . . . . . . . . . . . . . . . 5
   5.  Example Messages  . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  Initial Send  . . . . . . . . . . . . . . . . . . . . . . . 6
     5.2.  Restart . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8





























Harding                   Expires July 30, 2011                 [Page 2]


Internet-Draft              Abbreviated Title               January 2011


1.  Introduction

   AS2 [RFC4130] has experienced widespread adoption and is continually
   being asked to send or receive larger files by the business
   community.  As the size of the file transfers increase it has become
   evident that a mechanism is required that will allow trading partners
   to restart failed transfers from the point of failure.  This document
   will outline a method of implementing a failed transfer restart
   mechamism using existing HTTP headers so backwards compatibilty will
   exist with AS2 servers not wishing to support AS2 Restart.


2.  Overview

   Clients wishing to utilize the AS2 Restart mechanism for a particular
   file transfer will include the HTTP ETAG header which contains an
   unique transfer-id.  The message will contain an HTTP Content-Range
   header indicating the start and end byte range of the message.  The
   receiving HTTP server will utilize the ETAG and Content-Range headers
   to perform a temporary cache of the received file.  In the event of a
   transfer failure a restart from the point of failure can occur.  A
   client can query a server using the HTTP HEAD request to determine
   the number of bytes of data already received by the server.  The HTTP
   Head request will contain an ETAG header with a transfer-id of a
   previous transfer so the server can respond with a Content-length
   header value equalling the number of bytes already received from a
   previous transfer.


3.  Protocol

3.1.  Transfer ID

   The transfer id is a unique value that references a previous file
   transfer.  The uniqueness of the transfer id is guaranteed by the
   sending client and will reference only one instantiation of a
   particular file transfer.  The transfer id will follow the
   definitions of an entity tag as per [RFC2616] section 3.11 minus the
   weak indicator.

3.2.  HEAD Query

   The HEAD query will be used by the sending client to query a server
   as to the status of a previous file transfer.  The server will
   respond to the HEAD query with the number of bytes already received
   for a particular transfer-id value.  The returned Content-Length byte
   count is the number of bytes of the received content which does not
   include the http headers.  If the returned Content-Length value from



Harding                   Expires July 30, 2011                 [Page 3]


Internet-Draft              Abbreviated Title               January 2011


   the HEAD query equals the total instance value the sending system
   will send at least one byte of data in the next POST.  The value of
   the single byte that is transferred MUST equal the value of the last
   byte of data of the transferred message.  This will allow the client
   to restablish a network connection to the server while it waits for
   the appropriate response from the server.  The HEAD query MUST
   include the AS2-To and AS2-From headers from [RFC4130] to accommodate
   firewalls and proxies looking for the presence of these headers.

                                HEAD Query

   +-------------+    +-------------------+    +-------------+
   | HTTP Client |--->| Etag: transfer id |--->| HTTP Server |
   |             |    | AS2-To: receiverid|    |             |
   |             |    | AS2-From: senderid|    |             |
   |_____________|    |___________________|    |_____________|
       |                                           |
       |                                           |
       |    +---------------------------+          |
       -----| Response: 200 OK          |<---------
            | Content-Length: file size |
            |___________________________|


                                 Figure 1

   AS2 servers that do not understand the HEAD query or do not support
   AS2 Restart may return a non 200 ok response or return a Content-
   Length of zero.  In either case the client will (re)send the complete
   AS2 message to the server.

3.3.  POST

   A posted message will contain the ETAG header with an unique transfer
   id and a Content-Range header indicating the range of bytes contained
   within the message.  The Content-Range header value will be the range
   within the body of the message and does not include the http headers
   of the message.  A Content-Range header is not required if the
   sending client is sending a file for the first time or wishes to
   overwrite all existing data on the server.  However, if chunked
   transfer encoding is utilized a Content-Range header is recommended
   as some receiving systems implement a minimum file caching size and
   will not cache the inbound message if the message size cannot be
   determined from the inbound http headers.  If a server determines
   that the supplied Content-Range header field value is not valid the
   server MUST return an http response code of 416.  The returned 416
   http response will indicate the valid starting byte position for the
   requested resource, See [RFC2616] section 14.16.  Example: Content-



Harding                   Expires July 30, 2011                 [Page 4]


Internet-Draft              Abbreviated Title               January 2011


   Range: bytes */233333 The instance-length specifies the current
   length of the selected resource.

                                   POST

   +-------------+    +----------------------+    +-------------+
   | HTTP Client |--->| POST                 |    | HTTP Server |
   |             |    | Etag: transfer id    |--->|             |
   |             |    | Content-Range:       |    |             |
   |             |    |  bytes 0-1000/1001   |    |             |
   |_____________|    |______________________|    |_____________|
       +                                             |
       |                                             |
       |    +---------------------------+            |
       -----| Response: 200 OK          |<-----------
            |___________________________|


                                 Figure 2


4.  Important Considerations

   The HTTP restart server will be concerned with temp files bogging
   down the system disk space and should develop a routine to garbage
   collect any old (aged) files in the restart directory.  If a client
   queries the server about a existing file that was partially sent and
   the file was deleted due to aging from the system, the server will
   return a 200 ok response with a content-length of zero bytes.
   Therefore the client will be required to resend the complete message.

   The unique id mentioned earlier in this document must be unique so no
   two systems create the same id.

   It is strongly recommended that the Content-Range header be included
   in all POSTed messages as some systems use the values present in the
   header to determine inbound file size and whether this exceeds a
   minimum file size restriction for caching files.


5.  Example Messages










Harding                   Expires July 30, 2011                 [Page 5]


Internet-Draft              Abbreviated Title               January 2011


5.1.  Initial Send

                               HEAD Command

   HEAD /exchange/axway1 HTTP/1.1\n
   Etag: "ci1257348820455.829541_tharding_2k_te"
   AS2-To: sender_id
   AS2-From: receiver_id
   AS2-Version: 1.2
   Connection: close
   Host: yourhost.com

   The HEAD request is used to query the server to determine if a
   partially transfered file exists on the server.  The HEAD request
   MUST contain the AS2-To and AS2-From header fields with the
   identifiers associated with the cached file.  The AS2-Version value
   MUST be 1.2.  The format of the included AS2 header fields are
   defined in [RFC4130] Section 6.1.  The HEAD request query is OPTIONAL
   before the initial send of a document, however some systems may use
   the HEAD request as a way to determine if the ETAG value is already
   in use.

                                 Response

   HTTP/1.1 200 OK
   Connection: close
   Content-Length: 0

   The returned Content-Length value indicates the number of bytes
   associated with a specific transfer that resides on the server.  A
   returned Content-Length value of 0 indicates that the server does not
   have a partially saved file or the server does not support AS2
   restart.  In either case the sending system will send all bytes
   associated with a message.  Non 2xx http return codes will indicate
   that the receiving server does not support AS2 restart.

                               POST Command

   POST /exchange/axway1 HTTP/1/1
   <existing AS2 HTTP header fields>
   Etag: "ci1257348820455.829541_tharding_2k_te"
   Content-Length: 307502443

   <Message body>

   The initial POST of a message SHOULD include a method to determine
   the overall size of the incoming message.  This can be a Content-
   Length header field or a Content-Range header field or both.  Systems



Harding                   Expires July 30, 2011                 [Page 6]


Internet-Draft              Abbreviated Title               January 2011


   that support a min file size for restart will required at least one
   of the these headers.

5.2.  Restart

                               HEAD Command

   HEAD /exchange/axway1 HTTP/1.1\n
   Etag: "ci1257348820455.829541_tharding_2k_te"
   AS2-To: sender_id
   AS2-From: receiver_id
   AS2-Version: 1.2
   Connection: close
   Host: yourhost.com

                                 Response

   HTTP/1.1 200 OK
   Connection: close
   Content-Length: 65982464

   The returned Content-Length value indicates the number of bytes of
   data already received from a previous send.  This value does not
   include the HTTP headers of the message but only the Content data.

                               POST Command

   POST /exchange/axway1 HTTP/1/1
   <existing AS2 HTTP header fields>
   Etag: "ci1257348820455.829541_tharding_2k_te"
   Content-Range: bytes 65982464-307502442/307502443
   Content-Length: 241519979

   <Message body>

   A message that is resent will indicate the starting byte of the
   content data by using the Content-Range header.  The Content-Range
   header value will indicate the first byte and the last byte of the
   message.


6.  IANA Considerations

   This memo includes no request to IANA.







Harding                   Expires July 30, 2011                 [Page 7]


Internet-Draft              Abbreviated Title               January 2011


7.  Security Considerations

   Refer to the Security Considerations section of AS2 [RFC4130].


8.  Normative References

   [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.

   [RFC4130]  Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-
              Peer Business Data Interchange Using HTTP, Applicability
              Statement 2 (AS2)", RFC 4130, July 2005.


Author's Address

   Terry Harding (editor)
   Axway
   Phoenix, Arizona  85054
   US

   Phone:
   Email: tharding@us.axway.com


























Harding                   Expires July 30, 2011                 [Page 8]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/