axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [Axis2] MTOM issues and progress
Date Wed, 27 Jul 2005 12:48:03 GMT
Please see below

On 7/27/05, Thilina Gunarathne <> wrote:
> - there are so many while loops which don't check if there are any
>  more characters in the stream
> We are checking for end of stream in two places..
> If the message ends in the MIME standard way it should have "--" as a suffix
> to the last mime boundary... We check for that whenever we read a Mime part.
> Then we will be setting a Flag in the MIMEHelper 
> In the case if the message does not end as it is said in MIME, We'll be
> checking the size of the MIME part whenever we  read a mime Part. If it's
> Zero we assume that the Stream has ended and throws an Exception..

Thilina, It's VERY easy to launch an denial of service attack based on
this information. Do you see what i mean?

>  - are u handling unsupported media exception? are we throwing it. are
>  we catching it? are we handling all the exceptions in the specs? are
>  there test cases for it?
> We are not handling any unsupported media exception. I doubt whether we need
> to support any. If it is unknown we can always send it as Application/Octet
> Stream....
>  Specs does not define any exceptions explicitly.
>  We are handling exceptions regarding to handling of MIME parts. We handle
> the following cases....
>  Referred part is not found (if content-id is not found in any of the parts)
>  two parts contain same content-id (this will be caught only when the second
> part is parsed) We don't handle the case if somebody referenced a MIME Part
> using content location...
>  Is there any more exceptions we need to handle....

Can u check the interop tests at W3C?

>  - are we handling all the http status codes specified in mtom/xop specs?
> IMHO this is out of scope of MTOM ..... + spec does not define any such
> things.

#1) When we can get an exception from .NET the status text is lost. Am
not talking just about MTOM, Specifically this was an Unsupported
Media Exception from .NET

#2) When we get "400 Bad Request" from server, we don't handle it well
(AGAIN Axis2 not just MTOM). We end up trying to parse the payload
when there is nothing there.

>  - why are we createing intermediate ByteArrayOutputstreams and putting
>  things in them. what is going to happen if we get 1 GB attachment or
>  512 MB soap part? there should not be any intermediate storage
>  especially of things that are likely to grow.
> We use ByteArrayOutputStreams only to buffer and store the SOAP Envelope
> created by the Stream Writer... IMO it's a very rare situation for a SOAP
> envelope to be that big when we are using attachments... The future  plan
> for this problem is to come up our own MIME Writer so that we'll be able to
> use the actuall OutputStream for the Stream Writer. 
>  We don't store any attachments in ByteArrayOutputStreams..

Please add comments in the code and mark it with TODO.

>  - was there any effort to at least architect the code so that we can
>  add mime and SwA later when we get a chance?
>  We have provided basic support for SwA in .9...  We even tested sending
> MTOM message to Axis 1.2. Axis1.2 successfully recognised it as SwA.

Am talking about Axis2 code here. 
- We need a way to specify the type of attachment to send? (SwA vs MTOM). 
- We need to be able to say use XOP but don't make the mimepart's on
the wire (See interop scenarios)

>  - Can we get rid of httptransportsender as we talked about earlier?
> Yep.. MTOM is not tightly coupled to any transport...... This is already
> done......

Can we please delete the code or move it into the archive? am not
quite sure if this is done already. The only way to know if if people
start screaming and tests fail because the code in question was moved

>  Regards,
>  ~Thilina
>  -- 
> "May the SourcE be with u" 

Davanum Srinivas -

View raw message