123044 - charset should be on nsIChannel, not nsIHttpChannel

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

Per IRC discussion with Darin, we should expose charset on nsIChannel, not
nsIHttpChannel.  Then parts of multipart channels should also expose their
charsets.

Comment 1

[Darin Fisher]

cc'ing some folks who might have input on this.

Comment 2

[Doug Turner (:dougt)]

there are more channels than not which do not care about charsets.  Why forces
this on them?

Comment 3

[Darin Fisher]

dougt:

true, but it is very common for nsIChannel clients to want to know if there is
charset information.  just like contentLength and contentType, these values can
have defaults which mean "channel doesn't know."  eg. we could use a value of
NULL to indicate an unknown charset.

also, it just seems like something you'd generically need if given a random data
stream.  things like contentType and contentLength make sense, and so does
contentCharset.  it's a way of identifying the data in a generic way.  therefore
seems appropriate to provide it on nsIChannel.

IMO the fact that many protocols don't provide a charset doesn't necessarily
justify leaving it off of nsIChannel.

Comment 4

[rpotts (gone)]

Yep... I agree.  The notion of 'charset' needs to be pushed up into nsIChannel.

Since we expose the content-type at the nsIChannel level, we need to provide
charset info so consumers know how to interpret "text/..." content without
relying on protocol-specific interface methods...

RFC 2277 also puts forth an argument for having the 'charset available for ALL
protocols...'  (just to reference an RFC :-))

Will this remain a 'readonly attribute string' ?

i also think that we should document that the returned charset must be a IANA
registered name...  just to be clear that ALL protocols must use the same
charset namespace...

-- rick

Comment 5

[Darin Fisher]

it should probably be a r/w attribute so content sniffers can assign/override
default charset as specified by the channel impl.

Comment 6

[Darin Fisher]

-> me

Comment 7

[rpotts (gone)]

sounds good to me ;-)

-- rick

Comment 8

[Darin Fisher]

-> 1.0

Comment 9

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 10

[Darin Fisher]

forgot to add topembed on this one.

Comment 11

[Darin Fisher]

fixed-on-trunk

see patch in bug 128508

created nsIChannel::contentCharset, removed nsIHttpChannel::charset.

Comment 12

[benc]

VERIFIED:
http://lxr.mozilla.org/mozilla1.0/source/netwerk/base/public/nsIChannel.idl#118
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsIHttpChannel.idl&root=/cvsroot&subdir=mozilla/netwerk/protocol/http/public&command=DIFF_FRAMESET&rev1=1.7&rev2=1.8