On Wed, 22 Aug 2001, Keith Wannamaker wrote:
> I want to be able to support chunked encoding through ajpv13
> in TC 3.3. Apache decodes the body for us, it is only a matter
> of making the distinction between an unknown content-length
> an a zero content-length. Costin I'd like to tweak what
> you did here.. do you have an opinion on the matter?
I suppose you're talking about chunked encoding on the input ?
Because on the output I have absolutely no idea on how this could be done
- we don't have enough API for that.
On input - if I remember corectly, the input will have no Content-Length.
In Request you have "available" which is decremented on Ajp13.read() -
you can probably leave it to 1, and detect the end of the stream by the
return value of Ajp13.read().
On facade, you have the limit, which is set to the value of
Content-Length. The value -1 means 'unknown' acording to the spec, so we
should fix this in facade ( and make sure 0 is returned if there's no
body ).
The current mechanism is not the best - we shouldn't use Content-Length,
but let the connector signal the end of the stream.
Now the big question is when and where to make the changes. I don't feel
very good about doing anything big for 3.3, at least not on Ajp13. I think
we can do few fixes in the facade, with a lot of care.
For changes in connector - I sugest you use jakarta-tomcat-connector for
that, and probably the Ajp14 connector. Right now most of the work is in
finishing 3.3, but after that we'll have much more activity there. There
are many other nice things on the line, and that would fit very well.
How soon do you need this ? Does it have to be in 3.3, or can it be
delivered later, as an add-on module ( or fix ) ?
> http://cvs.apache.org/viewcvs/jakarta-tomcat/src/facade22/org/apache/tomcat/faca
> de/ServletInputStreamFacade.java.diff?r1=1.2&r2=1.3
> But by the way.. shouldn't that last return 0 be a -1?
It should. We need to fix this one for sure.
Costin
