tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya goberman <>
Subject RE: How to disable chunked encoding for the Http11NioProtocol connector.
Date Wed, 05 Jan 2011 22:43:56 GMT

This is getting philosophical. "spec-respectful" does not mean it has to support only one
valid protocol out of 2. If both protocol A (chunked-encoding) and B (no chunked encoding)
is allowed, why not give an ability to use whatever user prefers.

As far as "sputnik" example is concerned, I have never heard of a proxy server adding chunked
encoding to a non-chunked encoding input (most proxy servers are still HTTP 1.0 compliant).
Even if it does, it will be very small percent of overall users.
Anyway, from the practical perspective, if I can save 10% of bandwidth and work around some
bugs, I would take it.


> Date: Wed, 5 Jan 2011 23:13:07 +0100
> From:
> To:
> Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector.
> Correct me if I am wrong, but it seems to me that both in the case of this post, and

> another simultaneous one entitled "Tomcat and HTTP chunk extensions", the OP's are trying

> to use HTTP in a way that is not really part of the protocol design.
> The transfer-encoding is not supposed to be something over which the application has
> control.  Its purpose is to allow the safe transport of the message from end to end,
> is basically the choice of any intermediate agent.
> RFC 2616 :
> 3.6 Transfer Codings
> Transfer-coding values are used to indicate an encoding transformation that has been,
> be, or may need to be applied to an entity-body in order to ensure "safe transport" 
> through the network.
> and
> 4.3 Message Body
> ...
> Transfer-Encoding is a property of the message, not of the
> entity, and thus MAY be added or removed by any application along the request/response
> and
> 4.4 Message Length
> ...
> All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding

> (section 3.6), thus allowing this mechanism to be used for messages when the message

> length cannot be determined in advance.
> ...
> I am not saying that the OP's do not have valid reasons to want what they want, but maybe

> they should consider writing their own specialised server to do that, rather than asking

> for modifications to "spec-respectful" servers such as Apache httpd or tomcat ?
> After all, both are open-source and can be used as base to do that.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message