----- Original Message -----
From: "Jan Luehe" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
