Darin Fisher wrote:
> Consider the implementation of a reusable server connection for protocol
> foo, which is a nsIChannel. Various consumers of the server connection
> may wish to issue requests and wait for a response. While issueing a
> request, the server connection may be in the middle of processing a
> response for a previously issued request. In this case, the
> content-type of the data being read could very well differ from the
> content-type of the data being written. Clearly the content-type of the
> channel is not well defined in this case.
Agreed. Thanks for providing an example. Note, this example is ficticious.
> So, the question then becomes: do we want to support such a design? I
> say yes... especially since we can.
This is the part of pushing the content-type out to the request level I can be
convinced
of wanting. It can be easily added. Again, my primary concern is changing the
semantics of
when something is considered "open" and of channel users banking on content type info
*before* a channel has been opened.
> Moreover, there is no reason to force the assumption that the
> content-type of a URI will never change. Consider a HTTP server
> response that should not be cached. The URL could be
> http://www.foo.com/bar. First, it could return XML, and then 5 seconds
> later, it could return index.html. Until we have the headers from the
> server, there is no way to know, so why lock ourselves into the
> assumption that the content-type for a particular URL is static?
I see your point. I'm saying that there are too many assumptions made elsewhere in the
system to be able to handle this case. Maybe things have changed to the point that this
can be changed.
> Consumers of nsIChannel should understand that without a successful
> request, there is no way of knowing the content-type for a particular
> URI.
I've been singing that tune for 1.5 years :-). The operative word is "should." We found
that enforcing this layer wasn't doable. The flow change can have dramatic impact.
> The best you can do (without a successful request) is to guess the content-type
>using
> the MIME service.
And that's what channel:getcontenttype's current do.
Jud
