You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jan Luehe <Ja...@Sun.COM> on 2003/07/10 18:18:43 UTC
[5.0] [PROPOSAL] Make output buffer size limit configurable
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a "Content-Length" header. Instead, it includes a "Transfer-Encoding"
header whose value is "chunked":
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above "setLimit" calls would not
occur and the response would always include a "Content-Length" header,
no matter how big.
I am proposing a CoyoteConnector attribute "outLimited" (I am open to
other naming suggestions), whose possible values may be "TRUE" (default)
or "FALSE": if "TRUE", the output buffer size limit is set to the output
buffer size (current behaviour), and if "FALSE", an output buffer may
grow infinitely.
Comments?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Jan Luehe <Ja...@Sun.COM>.
Marc,
>>>>It can also be useful if you have a client that doesn't support "chunked
>>>>encoding" - which is probably true for a _lot_ of scripting tools.
>>>>If there is any other way to have the response not use chunked encoding,
>>>>then I agree this is not needed.
>>>>
>>>>Do we still support HTTP/1.0 or some request header to disable the
>>>
>>>encoding?
>>>
>>>
>>>AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical
>>>to Apache/httpd.
>>
>>I noticed that if I send a request specifying HTTP/1.0 as the protocol
>>version, and the response exceeds the output buffer, TC returns an
>>HTTP/1.1 response with neither a "Content-Length" nor a
>>"Transfer-Encoding: chunked" header.
>>
>>I would have expected it to include a "Content-Length" header. Would you
>>agree?
>
>
> It, umh, can't do that for dynamic content without buffering the
> whole response since it doesn't know how long it is.
>
> Hence the main reason for chunked encoding and the requirement
> HTTP/1.1 clients support it.
>
> Any HTTP/1.1 client must support chunked encoding, if not then it is
> broken and really don't need to be taken into account. If someone
> doesn't want to support chunked encoding, they shouldn't be making
> HTTP/1.1 requests.
just for the record, and I'll shut up after this.
What you are saying is correct, but does not address the specific
scenario I was testing. If you read my email again, you'll notice that
my client was sending an HTTP/1.*0* request.
What I was trying to test is if chunked encoding can be turned off if
the client pretends to only support HTTP/1.0, since chunked encoding is
a feature of HTTP/1.1.
Remy has answered my question.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Remy Maucherat <re...@apache.org>.
Marc Slemko wrote:
> On Mon, 14 Jul 2003, Jan Luehe wrote:
>>I would have expected it to include a "Content-Length" header. Would you
>>agree?
>
>
> It, umh, can't do that for dynamic content without buffering the
> whole response since it doesn't know how long it is.
Not even that does work, actually. The problem occurs if the servlet
flushes the response before closing it. If that happens, then part of
the response must be sent right away, regardless of the response state.
I don't know if you've seen that a lot (I have), but a lot of servlet
authors do, at the end of their servlets, somthing like:
out.flush();
out.close();
This forces use of chunking (or a connection close in HTTP/1.0 with
keep-alive).
> Hence the main reason for chunked encoding and the requirement
> HTTP/1.1 clients support it.
>
> Any HTTP/1.1 client must support chunked encoding, if not then it is
> broken and really don't need to be taken into account. If someone
> doesn't want to support chunked encoding, they shouldn't be making
> HTTP/1.1 requests.
Yes, that's the idea :)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 14 Jul 2003, Jan Luehe wrote:
> >>It can also be useful if you have a client that doesn't support "chunked
> >>encoding" - which is probably true for a _lot_ of scripting tools.
> >>If there is any other way to have the response not use chunked encoding,
> >>then I agree this is not needed.
> >>
> >>Do we still support HTTP/1.0 or some request header to disable the
> >
> > encoding?
> >
> >
> > AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical
> > to Apache/httpd.
>
> I noticed that if I send a request specifying HTTP/1.0 as the protocol
> version, and the response exceeds the output buffer, TC returns an
> HTTP/1.1 response with neither a "Content-Length" nor a
> "Transfer-Encoding: chunked" header.
>
> I would have expected it to include a "Content-Length" header. Would you
> agree?
It, umh, can't do that for dynamic content without buffering the
whole response since it doesn't know how long it is.
Hence the main reason for chunked encoding and the requirement
HTTP/1.1 clients support it.
Any HTTP/1.1 client must support chunked encoding, if not then it is
broken and really don't need to be taken into account. If someone
doesn't want to support chunked encoding, they shouldn't be making
HTTP/1.1 requests.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by David Wood <Da...@thestreet.com>.
Let's be nice to each other, Remy. I want to help.
My question was very specific. Why, when I check out TOMCAT_4_1_24, does
it not match what's in your jakarta-tomcat-4.1.24-LE-jdk14.zip source
bundle?
The bugzilla #'s aren't closed, but I want to be sure these fixes are
already in, and provide a more useful diff.
Remy Maucherat <re...@apache.org> wrote on 07/15/2003 09:54:08 AM:
> David Wood wrote:
>
> > Speaking of jasper, I'm very sorry to interrupt again, and I know it's
bad
> > etiquette to repeat myself, but I have two patches to outstanding bugs
in
> > Jasper and I'm just asking for a little help navigating your CVS
> > repository so I can make it easy for you to get them in.
> >
> > Details here:
> >
> >
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg44405.html
>
> I recommend you experiment more with CVS, which is a basic requirement
> for dealing with OSS projects.
>
> - source bundles are available
> - you should contribute patches for TC 5 if you can; you can send
> patches for TC 4.1, but they are less likely to be integrated
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Remy Maucherat <re...@apache.org>.
David Wood wrote:
> Speaking of jasper, I'm very sorry to interrupt again, and I know it's bad
> etiquette to repeat myself, but I have two patches to outstanding bugs in
> Jasper and I'm just asking for a little help navigating your CVS
> repository so I can make it easy for you to get them in.
>
> Details here:
>
> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg44405.html
I recommend you experiment more with CVS, which is a basic requirement
for dealing with OSS projects.
- source bundles are available
- you should contribute patches for TC 5 if you can; you can send
patches for TC 4.1, but they are less likely to be integrated
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by David Wood <Da...@thestreet.com>.
Speaking of jasper, I'm very sorry to interrupt again, and I know it's bad
etiquette to repeat myself, but I have two patches to outstanding bugs in
Jasper and I'm just asking for a little help navigating your CVS
repository so I can make it easy for you to get them in.
Details here:
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg44405.html
Regards,
-David
Remy Maucherat <re...@apache.org> wrote on 07/15/2003 03:39:20 AM:
> Jan Luehe wrote:
> > I noticed that if I send a request specifying HTTP/1.0 as the protocol
> > version, and the response exceeds the output buffer, TC returns an
> > HTTP/1.1 response with neither a "Content-Length" nor a
> > "Transfer-Encoding: chunked" header.
> >
> > I would have expected it to include a "Content-Length" header. Would
you
> > agree?
>
> Of course not, this is completely valid.
>
> The server must:
> - return the highest protocol version it supports
> - close the connection to indicate the end of the response if the
> content-length is not set
>
> I'm wondering why you're desperately trying to find things to fix in
> Coyote HTTP/1.1, which AFAIK is quite good in terms of HTTP compliance.
> There are still things that can be improved in there, such as the
> compression support (but I plan to help, since I'm done with my 5.0.x
> feature list), but these are not critical features.
> If I could choose, I'd prefer you help fix issues on Jasper, since you
> know it well and there are still bugs to fix ;-)
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> I noticed that if I send a request specifying HTTP/1.0 as the protocol
> version, and the response exceeds the output buffer, TC returns an
> HTTP/1.1 response with neither a "Content-Length" nor a
> "Transfer-Encoding: chunked" header.
>
> I would have expected it to include a "Content-Length" header. Would you
> agree?
Of course not, this is completely valid.
The server must:
- return the highest protocol version it supports
- close the connection to indicate the end of the response if the
content-length is not set
I'm wondering why you're desperately trying to find things to fix in
Coyote HTTP/1.1, which AFAIK is quite good in terms of HTTP compliance.
There are still things that can be improved in there, such as the
compression support (but I plan to help, since I'm done with my 5.0.x
feature list), but these are not critical features.
If I could choose, I'd prefer you help fix issues on Jasper, since you
know it well and there are still bugs to fix ;-)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Jan Luehe <Ja...@Sun.COM>.
>>It can also be useful if you have a client that doesn't support "chunked
>>encoding" - which is probably true for a _lot_ of scripting tools.
>>If there is any other way to have the response not use chunked encoding,
>>then I agree this is not needed.
>>
>>Do we still support HTTP/1.0 or some request header to disable the
>
> encoding?
>
>
> AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical
> to Apache/httpd.
I noticed that if I send a request specifying HTTP/1.0 as the protocol
version, and the response exceeds the output buffer, TC returns an
HTTP/1.1 response with neither a "Content-Length" nor a
"Transfer-Encoding: chunked" header.
I would have expected it to include a "Content-Length" header. Would you
agree?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Saturday, July 12, 2003 8:41 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
> Remy Maucherat wrote:
>
> > Bill Barker wrote:
> >>>How about making the output buffer size limit configurable?
> >>>(A value of "-1" could mean indefinite growth, if people know what they
> >>>are doing.)
> >>
> >> I also dislike the proposal, but since it's configurable, and off by
> >> default
> >> I can limit myself to -0. The biggest problem I see is that "if people
> >> know what they are doing", then they would never dream of enabling the
> >> option :).
> >
> > I will vote -1 to the proposal:
> > - this has no actual performance benefits that I can see
> > - this is equivalent to a "benchmark" flag, where the server is slightly
> > faster, but isn't useful for anything but throughtput testing (since the
> > server would eventually just die)
> >
> > Do you see such a benchmark setting in the HTTPd ? I think not.
> > I have nothing about people optimizing code, but the optimizations
> > should have an actual usefulness (such as tag pools, which some people
> > like). If the optimization makes the server unusable, then it shouldn't
> > be there.
>
>
> It can also be useful if you have a client that doesn't support "chunked
> encoding" - which is probably true for a _lot_ of scripting tools.
> If there is any other way to have the response not use chunked encoding,
> then I agree this is not needed.
>
> Do we still support HTTP/1.0 or some request header to disable the
encoding?
>
AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical
to Apache/httpd.
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Bill Barker wrote:
>>>How about making the output buffer size limit configurable?
>>>(A value of "-1" could mean indefinite growth, if people know what they
>>>are doing.)
>>
>> I also dislike the proposal, but since it's configurable, and off by
>> default
>> I can limit myself to -0. The biggest problem I see is that "if people
>> know what they are doing", then they would never dream of enabling the
>> option :).
>
> I will vote -1 to the proposal:
> - this has no actual performance benefits that I can see
> - this is equivalent to a "benchmark" flag, where the server is slightly
> faster, but isn't useful for anything but throughtput testing (since the
> server would eventually just die)
>
> Do you see such a benchmark setting in the HTTPd ? I think not.
> I have nothing about people optimizing code, but the optimizations
> should have an actual usefulness (such as tag pools, which some people
> like). If the optimization makes the server unusable, then it shouldn't
> be there.
It can also be useful if you have a client that doesn't support "chunked
encoding" - which is probably true for a _lot_ of scripting tools.
If there is any other way to have the response not use chunked encoding,
then I agree this is not needed.
Do we still support HTTP/1.0 or some request header to disable the encoding?
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Saturday, July 12, 2003 12:21 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
> Bill Barker wrote:
> >>How about making the output buffer size limit configurable?
> >>(A value of "-1" could mean indefinite growth, if people know what they
> >>are doing.)
> >
> > I also dislike the proposal, but since it's configurable, and off by
default
> > I can limit myself to -0. The biggest problem I see is that "if people
know
> > what they are doing", then they would never dream of enabling the option
:).
>
> I will vote -1 to the proposal:
> - this has no actual performance benefits that I can see
> - this is equivalent to a "benchmark" flag, where the server is slightly
> faster, but isn't useful for anything but throughtput testing (since the
> server would eventually just die)
>
> Do you see such a benchmark setting in the HTTPd ? I think not.
> I have nothing about people optimizing code, but the optimizations
> should have an actual usefulness (such as tag pools, which some people
> like). If the optimization makes the server unusable, then it shouldn't
> be there.
Ok, you've convinced me. Changing my vote to -1.
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
>>How about making the output buffer size limit configurable?
>>(A value of "-1" could mean indefinite growth, if people know what they
>>are doing.)
>
> I also dislike the proposal, but since it's configurable, and off by default
> I can limit myself to -0. The biggest problem I see is that "if people know
> what they are doing", then they would never dream of enabling the option :).
I will vote -1 to the proposal:
- this has no actual performance benefits that I can see
- this is equivalent to a "benchmark" flag, where the server is slightly
faster, but isn't useful for anything but throughtput testing (since the
server would eventually just die)
Do you see such a benchmark setting in the HTTPd ? I think not.
I have nothing about people optimizing code, but the optimizations
should have an actual usefulness (such as tag pools, which some people
like). If the optimization makes the server unusable, then it shouldn't
be there.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jan Luehe" <Ja...@Sun.COM>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, July 11, 2003 10:11 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
> Remy,
>
> > Jan Luehe wrote:
> >
> >> Currently, the limit up to which the size of an
> >> org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
> >> original buffer size:
> >>
> >> public OutputBuffer(int size) {
> >>
> >> bb = new ByteChunk(size);
> >> bb.setLimit(size);
> >> ...
> >> cb = new CharChunk(size);
> >> cb.setLimit(size);
> >> }
> >>
> >> As a result of this, if the response does not fit in the output
> >> buffer, the buffer is flushed, and the response does no longer include
> >> a "Content-Length" header. Instead, it includes a "Transfer-Encoding"
> >> header whose value is "chunked":
> >>
> >> Transfer-Encoding: chunked
> >>
> >> It may be useful (e.g., for some benchmarks such as TPC-W) to be able
> >> to configure a connector such that the buffer size of its responses
> >> grows infinitely, in which case the above "setLimit" calls would not
> >> occur and the response would always include a "Content-Length" header,
> >> no matter how big.
> >>
> >> I am proposing a CoyoteConnector attribute "outLimited" (I am open to
> >> other naming suggestions), whose possible values may be "TRUE"
> >> (default) or "FALSE": if "TRUE", the output buffer size limit is set
> >> to the output buffer size (current behaviour), and if "FALSE", an
> >> output buffer may grow infinitely.
> >>
> >> Comments?
> >
> >
> > -1. The performance impact of chunking on the server side is zero. If
> > you client bench program is dumb and its performance degrades with
> > chunking, fine, but please keep this "optimization" for SunOne ;-) Your
> > change basically does an automatic DoS condition on the server (simply
> > request a big file and boom).
>
> How about making the output buffer size limit configurable?
> (A value of "-1" could mean indefinite growth, if people know what they
> are doing.)
>
I also dislike the proposal, but since it's configurable, and off by default
I can limit myself to -0. The biggest problem I see is that "if people know
what they are doing", then they would never dream of enabling the option :).
>
> Jan
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy,
> Jan Luehe wrote:
>
>> Currently, the limit up to which the size of an
>> org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
>> original buffer size:
>>
>> public OutputBuffer(int size) {
>>
>> bb = new ByteChunk(size);
>> bb.setLimit(size);
>> ...
>> cb = new CharChunk(size);
>> cb.setLimit(size);
>> }
>>
>> As a result of this, if the response does not fit in the output
>> buffer, the buffer is flushed, and the response does no longer include
>> a "Content-Length" header. Instead, it includes a "Transfer-Encoding"
>> header whose value is "chunked":
>>
>> Transfer-Encoding: chunked
>>
>> It may be useful (e.g., for some benchmarks such as TPC-W) to be able
>> to configure a connector such that the buffer size of its responses
>> grows infinitely, in which case the above "setLimit" calls would not
>> occur and the response would always include a "Content-Length" header,
>> no matter how big.
>>
>> I am proposing a CoyoteConnector attribute "outLimited" (I am open to
>> other naming suggestions), whose possible values may be "TRUE"
>> (default) or "FALSE": if "TRUE", the output buffer size limit is set
>> to the output buffer size (current behaviour), and if "FALSE", an
>> output buffer may grow infinitely.
>>
>> Comments?
>
>
> -1. The performance impact of chunking on the server side is zero. If
> you client bench program is dumb and its performance degrades with
> chunking, fine, but please keep this "optimization" for SunOne ;-) Your
> change basically does an automatic DoS condition on the server (simply
> request a big file and boom).
How about making the output buffer size limit configurable?
(A value of "-1" could mean indefinite growth, if people know what they
are doing.)
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Currently, the limit up to which the size of an
> org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
> original buffer size:
>
> public OutputBuffer(int size) {
>
> bb = new ByteChunk(size);
> bb.setLimit(size);
> ...
> cb = new CharChunk(size);
> cb.setLimit(size);
> }
>
> As a result of this, if the response does not fit in the output
> buffer, the buffer is flushed, and the response does no longer include
> a "Content-Length" header. Instead, it includes a "Transfer-Encoding"
> header whose value is "chunked":
>
> Transfer-Encoding: chunked
>
> It may be useful (e.g., for some benchmarks such as TPC-W) to be able
> to configure a connector such that the buffer size of its responses
> grows infinitely, in which case the above "setLimit" calls would not
> occur and the response would always include a "Content-Length" header,
> no matter how big.
>
> I am proposing a CoyoteConnector attribute "outLimited" (I am open to
> other naming suggestions), whose possible values may be "TRUE" (default)
> or "FALSE": if "TRUE", the output buffer size limit is set to the output
> buffer size (current behaviour), and if "FALSE", an output buffer may
> grow infinitely.
>
> Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this "optimization" for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org