General question about huge attachments

[Rob Jellinghaus <ro...@unrealities.com>]

So I've heard from many people that there is a lot of interest in being able to send really large attachments via SOAP (and via Axis in particular).

My research indicates that Apache SOAP 2.2, at least, requires that there be a Content-Length header in every HTTP POST.  
Here's the fault you get without it:

Generated fault: 
  Fault Code   = SOAP-ENV:Protocol
  Fault String = Content length must be specified.

However, my reading of page 119 of http://www.ietf.org/rfc/rfc2616.txt indicates that Content-Length is not mandatory... it's a SHOULD, not a MUST.  (Interestingly, Apache SOAP 2.2 can deal just fine with missing Content-Length headers in the MIME body parts themselves!)

Content-Length, of course, is the bane of streaming (calculating the length of a huge encoded stream, before sending it, is a pain).  

My question to you all is, is it a bug that Apache SOAP *requires* a Content-Length even for HTTP POSTs that contain MIME messages?

My second question is, would it be desirable for Axis to *not* require Content-Length for HTTP POSTs that contain MIME messages?

I think the best possible outcome here would be an Axis that, when sending and receiving MIME messages (particularly with huge attachments), did no Content-Length calculations at all, instead just streaming directly from (say) files to the network.  I think this is even achievable, especially if Content-Length can be omitted.  (If Content-Length is not omittable in general, we could still put in hacks to try to calculate it up front, but it becomes much uglier.)  +1?  -1?
 
Thanks for any thoughts!
Cheers,
Rob

Re: SMTP transport

[Rob Jellinghaus <ro...@unrealities.com>]

There already is support for sessions in HTTP, via cookies.  They are optional, though.

A request/response identifier is different from a session, I think (different from an HTTP session, for sure).  I would say some kind of unique per-request ID in the SMTP header would be the way to go, since this request-reply matching is really an SMTP-transport-specific issue.

On the sending side, does the sending thread block waiting for the reply email?  Makes me wish we had asynchronous reply support in Axis....

Cheers,
Rob


At 08:02 AM 10/26/2001 -0400, Richard Boehme wrote:
>I'm working on an SMTP transport for Axis, and was wondering how a
>request/response pair should work. Since email isn't expected to be in the
>format of a request and a response, I'm wondering if there should be some
>form of session ID on each email, so that we can know which request
>produced which response. I don't think it should be treated as the next
>email recieved being the response; it looks like a race condition.
>
>--Richard
>
>

Re: General question about huge attachments

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

I would've loved to not have put content length into Apache SOAP.
Without a doubt it hurt performance even more.

However, not putting it prevents you from using the same HTTP
connection for multiple requests (keep alive). So, if you are
willing to lose keep alive capability then can forget Content-length.

Sanjiva.

----- Original Message -----
From: "Rob Jellinghaus" <ro...@unrealities.com>
To: <ax...@xml.apache.org>
Sent: Friday, October 26, 2001 6:39 AM
Subject: General question about huge attachments


> So I've heard from many people that there is a lot of interest in being
able to send really large attachments via SOAP (and via Axis in particular).
>
> My research indicates that Apache SOAP 2.2, at least, requires that there
be a Content-Length header in every HTTP POST.
> Here's the fault you get without it:
>
> Generated fault:
>   Fault Code   = SOAP-ENV:Protocol
>   Fault String = Content length must be specified.
>
> However, my reading of page 119 of http://www.ietf.org/rfc/rfc2616.txt
indicates that Content-Length is not mandatory... it's a SHOULD, not a MUST.
(Interestingly, Apache SOAP 2.2 can deal just fine with missing
Content-Length headers in the MIME body parts themselves!)
>
> Content-Length, of course, is the bane of streaming (calculating the
length of a huge encoded stream, before sending it, is a pain).
>
> My question to you all is, is it a bug that Apache SOAP *requires* a
Content-Length even for HTTP POSTs that contain MIME messages?
>
> My second question is, would it be desirable for Axis to *not* require
Content-Length for HTTP POSTs that contain MIME messages?
>
> I think the best possible outcome here would be an Axis that, when sending
and receiving MIME messages (particularly with huge attachments), did no
Content-Length calculations at all, instead just streaming directly from
(say) files to the network.  I think this is even achievable, especially if
Content-Length can be omitted.  (If Content-Length is not omittable in
general, we could still put in hacks to try to calculate it up front, but it
becomes much uglier.)  +1?  -1?
>
> Thanks for any thoughts!
> Cheers,
> Rob
>

Re: SMTP transport

[Benjamin Szekely <bs...@cornell.edu>]

I ran into a similar problem with another transport.  Maybe put a message ID
in the subject line, or in an SMTP header.

request: subject: soap-request-1
response: subject: soap-response-1

Hope this helps.

   Ben


----- Original Message -----
From: "Richard Boehme" <bo...@acm.jhu.edu>
To: <ax...@xml.apache.org>
Sent: Friday, October 26, 2001 8:02 AM
Subject: SMTP transport


> I'm working on an SMTP transport for Axis, and was wondering how a
> request/response pair should work. Since email isn't expected to be in the
> format of a request and a response, I'm wondering if there should be some
> form of session ID on each email, so that we can know which request
> produced which response. I don't think it should be treated as the next
> email recieved being the response; it looks like a race condition.
>
> --Richard
>

SMTP transport

[Richard Boehme <bo...@acm.jhu.edu>]

I'm working on an SMTP transport for Axis, and was wondering how a
request/response pair should work. Since email isn't expected to be in the
format of a request and a response, I'm wondering if there should be some
form of session ID on each email, so that we can know which request
produced which response. I don't think it should be treated as the next
email recieved being the response; it looks like a race condition.

--Richard