> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 23, 2001 12:59 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: ajp13, tc 3.3
>
>
> On Thu, 23 Aug 2001, Larry Isaacs wrote:
>
> > > length, not no
> > > content. It should be a simple change, we just must make sure
> > > we check all
> > > places where ContentLength is used and fix it everywhere.
> >
> > To make sure I am in sync, exactly which spec are you refering to.
> > Thanks.
>
> ServletRequest.getContentLength(), in javadoc it says
> "returns -1 if the
> content length is unknown". ServletInputStream treats -1 as
> "no content".
>
> It's not a big deal, as most 'common' requests with a body will have a
> content length header, but it is legal to have a request with body but
> without content-lenght.
>
> That becomes interesting for SOAP with attachments, where the
> body starts
> to be 'interesting'. In many cases, if you have (many) large
> attachments,
> you'll not be able to buffer all of them to get the total
> count - or guess
> how big the result will be ( since MimeMultipart relys on
> separators that
> are random and hard to predict the size, etC).
>
> The fix in ServletInputStreamFacade is reasonably simple - if
> Content-Length is -1, rely on the adapter to signal the end
> of the request
> ( by returning -1 on doRead ). Every case that works today
> will still work
> ( since now it doesn't work without Content-Length anyway,
> we'll just make
> this other case to work too ).
I think this makes sense to do. I'll try to review and help test the
changes.
Larry
