I've been thinking about a few issues we have with content-type detection:
1) Our internal detection is not too reliable (for file://, ftp://, etc).
2) There is often context at channel open that could provide a better guess at
the type (eg the "type" attribute of <link>, <a>, or <script>).
At the same time we don't really want to make callers check whether a channel
is an HTTP channel and then ignore the channel's content type if it is... (for
example, data: channels should be treated just like http:// ones and consumers
should not have to hardcode such lists of channels).
I've been thinking about this a bit, and I have a possible approach:
A) Create a new interface (I'll call it nsIHintableChannel, but it could be
nsIChannel2 for all I care).
B) Place the function |void setContentTypeHint(ACString hint);| on
nsIHintableChannel.
C) Have various channels implement nsIHintableChannel (eg the data: channel
may not care to implement it).
D) Have places that have a type hint set the hint on the channel before
opening it, if the channel implements nsIHintableChannel.
Now the file:// and ftp:// channels can use the hint (if set) in preference to
detection by data-sniffing or extension-guessing, while the http:// channel and
data: channel can basically ignore it (HTTP/0.9 responses would probably want
to use the hint). Other channel implementations can decide for themselves what
to do with the hint and how to use it. The only condition, really, is that if
the hint is not set the behavior should not radically change from what it is
right now.
Thoughts? Comments? Suggestions? Criticisms?
Boris
--
Washington [D.C.] is a city of Southern efficiency and
Northern charm.
-- John F. Kennedy
