I think I would have to agree with Jean-Michel Leon says the expected behavior
is.
Since "text/html" is merely the default setting, any attempt to change it, be it
via setHeader or setContentType, should work. setContentType should just call
setHeader with the proper arguments, since it's just a convenience method
anyway. The app server should either check the headers it is about to send, and
only add "Content-Type: text/html" if it's not already set, or it should add its
default Content-Type to the correct position in the list of headers so that it
will be ignored if there is another Content-Type set (see my next paragraph).
This should be the case with any headers that have default values, not just
Content-Type.
As for your example of setting the content type twice, what is the HTTP
convention: does the first one win, or does the last one win? Or to make it
even simpler, just output both of the Content-Type headers in the order they
were created - the client can be trusted to stick to the HTTP spec and use the
correct one. I don't see any reason why setContentType should automatically
"win" over setHeader, or vice versa.
(BTW, setting the content type twice for one response is basically a programming
error, so handling it in any way other than the HTTP spec isn't necessary.)
If most experienced programmers would agree that this is what makes sense, the
reference implementation needs to be changed.
Date: Sun, 16 Jan 2000 23:30:15 -0800
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Subject: Re: Tomcat vs. JSWDK
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jean-Michel Leon wrote:
>
> this deliberate behavior in tomcat is wrong (i.e. it's a bug), because
> the servlet spec does not specify that servlets should override the
> programmer's contnet-type wth its own defaults.
>
In other words, you would like the following sequence of events:
<%
response.setHeader("Content-Type", "foo/bar");
response.setContentType("x-application/my-content-type");
%>
to result in a content type of "foo/bar", despite the fact that the programmer
explicitly sets it? Seems to me you could make a case that this is a bug, just
as
strongly as the argument you are making.
I remind you again -- in the case where the servlet spec is not speciific (it is
silent
on the topic you are raising regarding content type; not quite so silent on
content
length -- see the 2.2 API docs), i.e. it is an interpretation issue, the
reference
implementation defines correct behavior. And guess what the reference
implementation
here is?
>
> jm.
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
