Closed Bug 11965 Opened 25 years ago Closed 25 years ago

[FEATURE] libmime needs a way to detect the charset of the destination webshell (if available)

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rhp, Assigned: warrensomebody)

References

Details

After a newsgroup discussion, warren posted:

 > I'm not sure how you should get the webshell from libmime. This
 > is probably related to the infamous "event sink getter" architecture
 > that is yet to be determined. I want to do that next (for m10).

So I want to make sure we track this as we move towards beta.
Blocks: 5938
Target Milestone: M10
I marked this M10 per the comments above and to get off the 'Necko, no
milestone' radar. Feel free to change.
Status: NEW → ASSIGNED
Gagan, should this be an accessor on nsIChannel? Or should it be an event sink?
Rick said that he was going to add it nsIHTTPChannel. It doesn't make sense to
do it to nsIChannel. But for the moment if you need to parse out the charset,
you can see anything after the semicolon on a
nsIHTTPChannel::GetResponseHeader("Content-Type", &foo); which is the raw HTTP
header as compared to the nsI[HTTP]Channel::GetContentType() call. Cc'ing
rpotts.
Blocks: 12839
Spoke with warren at bug triage today.  Not an M10 blocker...moving to M11.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Looks like this has already been done. nsIHTTPChannel::GetCharset
Status: RESOLVED → VERIFIED
I trust warren, marking verified for tracking purposes.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
You need to log in before you can comment on or make changes to this bug.