RE: SOAP-Attachment question -> handling large attachment?

John,

Thanks for the reply. I did a little bit more research and got different
opinions.

Your explaination on Content-Disposition seems focusing on SOAP message
processing. If not, as being explained in
http://www.ietf.org/rfc/rfc2183.txt, 2.9 specifies this header is optional
in multipart body part which helps the presentation of the multipart. So
it's all right as an optional multipart body part header, right? The server
can choose use it or not.

Thanks,
Shuo

> -----Original Message-----
> From: John J. Barton [mailto:John_Barton@hpl.hp.com]
> Sent: Tuesday, October 09, 2001 11:07 AM
> To: Shuo Shen; 'xml-dist-app@w3.org'
> Subject: Re: SOAP-Attachment question -> handling large attachment?
> 
> 
> At 03:17 PM 10/8/2001 -0400, Shuo Shen wrote:
> >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:
> >
> >--MIME_boundary
> >Content-Type: image/tiff
> >Content-Transfer-Encoding: base64
> >Content-ID: <claim061400a.tiff@claiming-it.com>
> >Content-Disposition: attachment-data; name="attachment1";
> >filename="foo.tif""
> >
> >so we know we can persist the following data to a file 
> anyway no matter the
> >size;
> 
> In my opinion this solution would be inappropriate since it relies
> server assumptions about the client.  A 1k file may be "too big" for
> some clients; 100G may be "just fine" for another.  Moreover, files
> and filenames are artifacts of end point implementation that 
> should not
> be exchanged between clients and servers.
> 
> 
> >2. Or adding a Content-Length or Attachment-Length header 
> for each body part
> >
> >--MIME_boundary
> >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).
> 
> As far as I know this solution would be a good one based on 
> the positive
> experience that HTTP has had with Content-Length (ok, minus 
> the early days).
> However Content-Length is not intrinsically part of MIME as I 
> understand
> it.  MIME is designed to allow chunks of data to be moved 
> about, not long
> streams prefixed with control data.  HTTP stretched MIME; it 
> seems to have
> survived.
> 
> >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?
> 
> I don't believe that this fix should be made in SOAP-Attachments.
> Rather the nice solution would be a separate document on 
> Content-Length
> for Multipart MIME.  Then SOAP-Attachments could reference it.
> 
> 
> >Thanks,
> >Shuo
> 
> ______________________________________________________
> John J. Barton          email:  John_Barton@hpl.hp.com
> http://www.hpl.hp.com/personal/John_Barton/index.htm
> MS 1U-17  Hewlett-Packard Labs
> 1501 Page Mill Road              phone: (650)-236-2888
> Palo Alto CA  94304-1126         FAX:   (650)-857-5100
>

Received on Tuesday, 9 October 2001 15:13:27 UTC