You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rossen Stoyanchev <rs...@vmware.com> on 2013/05/04 21:43:52 UTC
Status 204 (no content) and Content-Type header
It appears that Tomcat ignores the Content-Type header when the status is set to 204 (No Content). I can see the rational for that, however is there a strong reason why Tomcat should care if it is set by the application? There are some corner cases [1].
Rossen
[1] https://github.com/sockjs/sockjs-protocol/blob/master/sockjs-protocol-0.3.3.py#L746
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Status 204 (no content) and Content-Type header
Posted by Rossen Stoyanchev <rs...@vmware.com>.
Thanks!
----- Original Message -----
> From: "Mark Thomas" <ma...@apache.org>
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Sent: Saturday, May 4, 2013 5:57:15 PM
> Subject: Re: Status 204 (no content) and Content-Type header
>
> On 04/05/2013 21:21, Mark Thomas wrote:
> > On 04/05/2013 20:43, Rossen Stoyanchev wrote:
> >>
> >> It appears that Tomcat ignores the Content-Type header when the
> >> status is set to 204 (No Content).
> >
> > Correct. It happens in AbstractHttp11Processor.prepareResponse()
> >
> >> I can see the rational for that,
> >> however is there a strong reason why Tomcat should care if it is
> >> set
> >> by the application?
> >
> > No.
> >
> > I took a look at RFC 2616. Section 10.2.5 states that a 204
> > response may
> > contain updated metainformation in the form of entity headers and,
> > as
> > per section 7.1, Content-Type is an entity header so it should be
> > not be
> > skipped if set for a 204 response.
> >
> > On those grounds, this is a Tomcat bug.
> >
> >> There are some corner cases [1].
> >
> > That looks more like a bug in 3rd-party code. Bugs in 3rd party
> > code are
> > rarely sufficient justification for changing Tomcat's behaviour. In
> > this
> > case, the RFC2616 argument is a much stronger one and it looks to
> > me
> > like the code will be changed (regardless of [1], not because of
> > it).
>
> Fixed in trunk and 7.0.x and will be in 7.0.40 onwards.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Status 204 (no content) and Content-Type header
Posted by Mark Thomas <ma...@apache.org>.
On 04/05/2013 21:21, Mark Thomas wrote:
> On 04/05/2013 20:43, Rossen Stoyanchev wrote:
>>
>> It appears that Tomcat ignores the Content-Type header when the
>> status is set to 204 (No Content).
>
> Correct. It happens in AbstractHttp11Processor.prepareResponse()
>
>> I can see the rational for that,
>> however is there a strong reason why Tomcat should care if it is set
>> by the application?
>
> No.
>
> I took a look at RFC 2616. Section 10.2.5 states that a 204 response may
> contain updated metainformation in the form of entity headers and, as
> per section 7.1, Content-Type is an entity header so it should be not be
> skipped if set for a 204 response.
>
> On those grounds, this is a Tomcat bug.
>
>> There are some corner cases [1].
>
> That looks more like a bug in 3rd-party code. Bugs in 3rd party code are
> rarely sufficient justification for changing Tomcat's behaviour. In this
> case, the RFC2616 argument is a much stronger one and it looks to me
> like the code will be changed (regardless of [1], not because of it).
Fixed in trunk and 7.0.x and will be in 7.0.40 onwards.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Status 204 (no content) and Content-Type header
Posted by Mark Thomas <ma...@apache.org>.
On 04/05/2013 20:43, Rossen Stoyanchev wrote:
>
> It appears that Tomcat ignores the Content-Type header when the
> status is set to 204 (No Content).
Correct. It happens in AbstractHttp11Processor.prepareResponse()
> I can see the rational for that,
> however is there a strong reason why Tomcat should care if it is set
> by the application?
No.
I took a look at RFC 2616. Section 10.2.5 states that a 204 response may
contain updated metainformation in the form of entity headers and, as
per section 7.1, Content-Type is an entity header so it should be not be
skipped if set for a 204 response.
On those grounds, this is a Tomcat bug.
> There are some corner cases [1].
That looks more like a bug in 3rd-party code. Bugs in 3rd party code are
rarely sufficient justification for changing Tomcat's behaviour. In this
case, the RFC2616 argument is a much stronger one and it looks to me
like the code will be changed (regardless of [1], not because of it).
Mark
>
> Rossen
>
> [1]
> https://github.com/sockjs/sockjs-protocol/blob/master/sockjs-protocol-0.3.3.py#L746
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org