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

RESOLVED FIXED in Bugzilla 3.0

Status

()

RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: guillomovitch, Assigned: guillomovitch)

Tracking

Bugzilla 3.0
Bug Flags:
approval +
approval3.0 +

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
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.
(Assignee)

Comment 1

12 years ago
Created attachment 261007 [details] [diff] [review]
Forementioned patch
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
(Assignee)

Updated

12 years ago
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
(Assignee)

Comment 7

12 years ago
It does affect 3.0, where i initially faced the issue.

Comment 8

12 years ago
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
Last Resolved: 12 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.