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.
Thanks
> Date: Wed, 5 Jan 2011 23:13:07 +0100
> From: a...@ice-sa.com
> To: users@tomcat.apache.org
> 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 real
> control. Its purpose is to allow the safe transport of the message from end
> to end, and
> 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, can
> 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 chain.
>
> 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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
