User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20070208 Mandriva/220.127.116.11-2mdv2007.1 (2007.1) Firefox/18.104.22.168 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.
Created attachment 261007 [details] [diff] [review] Forementioned patch
Attachment #261007 - Flags: review?
Please request review from firstname.lastname@example.org specifically instead of leaving the requestee box blank. :)
OS: Linux → All
Hardware: PC → All
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
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: 22.214.171.124; previous revision: 1.59 done
Status: NEW → RESOLVED
Last Resolved: 12 years ago
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.