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 h
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 provi
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.
Deta
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://w
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 pro
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-Leng
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
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 t
- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
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
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, July 12, 2003 12:21 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
> Bill Barker 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 tha
- 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 Lueh
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
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);
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.setLim
16 matches
Mail list logo
