Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4A325847.5070408@list-post.mks-mail.de>
Date: Fri, 12 Jun 2009 15:29:43 +0200
From: =?UTF-8?B?TWFya3VzIFNjaMO2bmhhYmVy?=
 <tomcat-users@list-post.mks-mail.de>
Reply-To: users@tomcat.apache.org
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.1.21) Gecko/20090409 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: chunked encoding
References: 
 <40D5E3C3CBE03D45A776E7C358BDE9080127DD58@missoula.formatdynamics.com>
 <4A31597A.6030508@list-post.mks-mail.de>
	 <40D5E3C3CBE03D45A776E7C358BDE9080127DD7F@missoula.formatdynamics.com>
 <4A317D8D.3060107@ice-sa.com>
 <40D5E3C3CBE03D45A776E7C358BDE9080127DDA6@missoula.formatdynamics.com>
 <4A32153A.5090401@list-post.mks-mail.de> <4A322370.8060607@kippdata.de>
 <4A3240D1.8050003@list-post.mks-mail.de> <4A324F35.4050909@ice-sa.com>
In-Reply-To: <4A324F35.4050909@ice-sa.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

André Warnier:

> In summary thus :
> 
> - making the request be HTTP 1.0, no matter how it's done, is not going 
> to magically make Tomcat send the response in one chunk nor add a 
> Content-Length header.

Exactly.

> (it may just /prevent/ it from adding a "Content-transfer-encoding: 
> chunked" header, yes ?)

It may prevent it from sending chunked content (and adding the
appropriate header) in 100% of the cases, since there's no chunked
transfer encoding in HTTP/1.0. IOW, you may replace "may" with "will" in
the above sentence ;-).

> - the first-choice solution would be to have the CDN fix their software, 
> or select another CDN which can handle chunked content.

I agree.

> - the second-best would be :
> (presuming the OP knows at some point the real size of the data chunk 
> that has to be sent back.)
> Write a servlet which obtains the data, then uses 
> response.setContentLength(nnn), then does a 
> response.getWriter/getOutputStream, then writes the data there. Yes ?
> 
> - if the above is not acceptable/practical, then another solution would 
> be to intercept and buffer the full response somewhere, calculate its 
> size, and then forward it unchunked, preceded by a proper Content-Length 
> header.

Yes.
I just noticed that the OP said he was going to experiment with setting
the bufferSize attribute of the AJP Connector to a higher value.
That might indeed be the easiest workaround - provided the output his
servlets/JSPs generate do not exceed the buffer size - and this
attribute really does what I understand it does.
Using ServletResponse#setBufferSize, which I already mentioned, might
work too - on an per servlet level. But if increasing the value of the
bufferSize attribute of the Connector works, it's much less hassle.

-- 
Regards
  mks

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org