ajp13, tc 3.3

[Keith Wannamaker <Ke...@Wannamaker.org>]

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?
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?

Keith

RE: ajp13, tc 3.3

[cm...@yahoo.com]

On Thu, 23 Aug 2001, Keith Wannamaker wrote:

> I think ajp is handling the missing content length case OK, except we
> might need to send an initial body chunk even if contentlength is not
> specified.
>
> I was hoping to get it in tc 3.3 since tc is not quite doing what one
> would expect from reading the spec.  How about I post a diff for review
> and we go from there?

What about this: we do the change in facade ( if Larry is +1 on this !),
since they are clearly breaking the spec: -1 means unknown 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.

I think Ajp13 connector can also be easily fixed.

For C side - I would sugest you do it in j-t-c. The code there has few
other enhancements, including the very nice configure, and can be used
instead of the native in the main branch. Also, if something bigger is
needed in the java side of the connector - I would use ajp14.

Costin

RE: ajp13, tc 3.3

[Keith Wannamaker <Ke...@Wannamaker.org>]

| -----Original Message-----
| I suppose you're talking about chunked encoding on the input ?

Yep.

| The current mechanism is not the best - we shouldn't use Content-Length,
| but let the connector signal the end of the stream.

Yes, exactly.  Both request and the facade input stream take an
unknown content length to be an eof state.  So, even if the data
is there, a servlet can't read it.

| 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.

I think ajp is handling the missing content length case OK, except we
might need to send an initial body chunk even if contentlength is not
specified.

I was hoping to get it in tc 3.3 since tc is not quite doing what one
would expect from reading the spec.  How about I post a diff for review
and we go from there?

|It should. We need to fix this one for sure.
Done.

Thanks for your input!
Keith

Re: ajp13, tc 3.3

[cm...@yahoo.com]

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