Closed Bug 376911 Opened 17 years ago Closed 17 years ago

Non-text content-types require setting the charset manually in the $cgi->header() call

Categories

(Bugzilla :: Reporting/Charting, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.0

People

(Reporter: guillomovitch, Assigned: guillomovitch)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.3) Gecko/20070208 Mandriva/2.0.0.3-2mdv2007.1 (2007.1) Firefox/2.0.0.3
Build Identifier: 

... and throw warnings in logs, such as when running duplicate.cgi to generate RDF from duplicate.cgi from collectstat.pl. See line 1428 in CGI.pm for detail:
$charset = $self->charset if $type =~ /^text\//;

Attached patch enforce utf8 charset in duplicates.cgi http headers if bugzilla is configured to use utf8. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Attachment #261007 - Flags: review?
Please request review from gerv@mozilla.org specifically instead of leaving the requestee box blank. :)
OS: Linux → All
Hardware: PC → All
Attachment #261007 - Flags: review? → review?(gerv)
Comment on attachment 261007 [details] [diff] [review]
Forementioned patch

Wow - that's dumb behaviour from CGI.pm.

r=gerv, with the comment changed to:

# We set the charset in Bugzilla::CGI, but CGI.pm ignores it unless the
# Content-Type is a text type. In some cases, such as when we are 
# generating RDF, it isn't, so we specify the charset again here.

Gerv
Attachment #261007 - Flags: review?(gerv) → review+
(In reply to comment #3)
> Wow - that's dumb behaviour from CGI.pm.

Not really. That's how RFC2045 and RFC2046 specifications define charset parameter. They say it's applicable only to text content type. Besides, it doesn't make any sense for image, audio and other binary types.

However, they do allow specification of new content types to define that a charset is valid for the new type. Looks like RFC3870 (application/rdf+xml) and RFC3023 (application/xml, text/xml and other XML types) do specify optional charset parameter. I do hope we use correct content type for our output. :)
Assignee: gerv → guillomovitch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: approval?
Target Milestone: --- → Bugzilla 3.2
That's strange that this doesn't work otherwise. But OK.
Flags: approval? → approval+
Doesn't this affect 3.0 too? If so, we should hold off checkin until after the release of 3.0 and then get it into 3.0.1.
Summary: Setting charset in http headers from Bugzilla::CGI object charset property doesn't work with content-types others as text subtype → Non-text content-types require setting the charset manually in the $cgi->header() call
It does affect 3.0, where i initially faced the issue.
tip:

Checking in duplicates.cgi;
/cvsroot/mozilla/webtools/bugzilla/duplicates.cgi,v  <--  duplicates.cgi
new revision: 1.60; previous revision: 1.59
done

3.0:

Checking in duplicates.cgi;
/cvsroot/mozilla/webtools/bugzilla/duplicates.cgi,v  <--  duplicates.cgi
new revision: 1.59.2.1; previous revision: 1.59
done
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: approval3.0+
Resolution: --- → FIXED
Target Milestone: Bugzilla 3.2 → Bugzilla 3.0
Version: unspecified → 3.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: