You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Thilina Gunarathne <cs...@gmail.com> on 2005/07/27 09:11:31 UTC
[Axis2] MTOM issues and progress
- 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..
1. 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
2. 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..
- 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....
1. Referred part is not found (if content-id is not found in any of
the parts)
2. 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....
- 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.
- 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..
- 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.
- Can we get rid of httptransportsender as we talked about earlier?
Yep.. MTOM is not tightly coupled to any transport...... This is already
done......
Regards,
~Thilina
--
"May the SourcE be with u"
http://www.bloglines.com/blog/thilina
Re: [Axis2] MTOM issues and progress
Posted by Davanum Srinivas <da...@gmail.com>.
FYI, Another potential DOS i noticed was that we go into some kind of
loop when the content-id specified in the soap body is not present in
the mime attachments.
-- dims
On 7/27/05, Davanum Srinivas <da...@gmail.com> wrote:
> Please see below
>
> On 7/27/05, Thilina Gunarathne <cs...@gmail.com> 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
> out.
>
> > Regards,
> > ~Thilina
> >
> > --
> > "May the SourcE be with u"
> > http://www.bloglines.com/blog/thilina
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: [Axis2] MTOM issues and progress
Posted by Davanum Srinivas <da...@gmail.com>.
Please see below
On 7/27/05, Thilina Gunarathne <cs...@gmail.com> 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
out.
> Regards,
> ~Thilina
>
> --
> "May the SourcE be with u"
> http://www.bloglines.com/blog/thilina
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/