I've searched archives but only found [1], which is only partly related.
Of course, commitResponse could be overridden in HttpEnvironment to
filter out some HTTP methods, but which ones ? Should we have a black
list, a white list, or a mean to configure it somewhere ? I don't want
to break some compatibility somewhere.
BTW, maybe only HEAD requests are concerned, after all ...
Cédric
[1]
http://cocoon.markmail.org/search/?q=content-length#query:content-length+page:4+mid:ddsqo5ezsstshh7a+state:results
Le 29/03/2017 à 19:14, Peter Hunsberger a écrit :
This sounds somewhat familiar, you may want to search the mailing list
archives to see if this has been discussed before.... Can
commitResponse tell what kind of request it is dealing with or if not
can that be passed in so that it knows?
Peter Hunsberger
On Wed, Mar 29, 2017 at 10:14 AM, Cédric Damioli <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I recently noticed that, at least for 2.1.x and 2.2.x, after any
request processing, Environment.commitResponse() is called which
has the side effect to compute the actual response body size and
then set the response content length.
While this is perfectly fine for GET requests, it's obviously
useless for OPTIONS and even wrong for HEAD requests.
Looking at code, an immediate workaround is to disable output
buffering but it's not satisfying.
Did someone encountered the same issue ?
I don't know exactly how to solve this without breaking legacy
behaviour.
Any thoughts ?
Regards,
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org <http://www.ametys.org>
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org
