W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

SOAP-Attachment question -> handling large attachment?

From: Shuo Shen <sshen@softartisans.com>
Date: Mon, 8 Oct 2001 15:17:25 -0400
Message-ID: <07DF638B962FD2118DF800A0C9D61D6F7BC755@ATLAS>
To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
I got this list name from http://www.w3.org/TR/SOAP-attachments. Hope this
is the right place to ask the question.

From implementation of a SOAP-Attachment request, I have trouble to figure
out how to allocate resource for the attachment part. We want to scale up
our apps to deal with attachment of Gig size level (1-100G bytes). Normally,
we can use either memory or a temporary file to persist the data before
processing SOAP logic. However, to use memory for 100G data, that's not
going to work(in today's most application :). We expect SOAP-Attachment
draft giving us some criteria on this.

Specifically, we suggest about two ways:
1. Adding a http-like Content-Disposition header to each body part, which
will have sth like:

Content-Type: image/tiff
Content-Transfer-Encoding: base64
Content-ID: <claim061400a.tiff@claiming-it.com>
Content-Disposition: attachment-data; name="attachment1";

so we know we can persist the following data to a file anyway no matter the

2. Or adding a Content-Length or Attachment-Length header for each body part

Content-Type: image/tiff
Content-Transfer-Encoding: base64
Content-ID: <claim061400a.tiff@claiming-it.com>
Content-Length: 12345

so we can allocate resources best fit the Content-Length. If it's small,
into memory(for efficiency); if it's big, into file system(for scale).

It's not a question on SOAP as a wire protocol, but on how to do it in
reality. Just like the other thread talking about how to identify the
SOAP-Attachment's SOAP/XML part, it's important for the implemention.

What do you suggest? Or is there something somebody can put into the
SOAP-Attachment documentation for this?

Received on Monday, 8 October 2001 15:21:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC