all bugzilla pages should specify charset

RESOLVED FIXED in Bugzilla 2.14



18 years ago
5 years ago


(Reporter: Jesse Ruderman, Assigned: Matthew Barnson)


Bugzilla 2.14


(Whiteboard: security code, URL)



18 years ago
to prevent untrusted content on bugzilla from executing possibly malicious 
javascript code, each page should include a charset at the top.



18 years ago
Blocks: 38852
Whiteboard: 2.14


17 years ago
Whiteboard: 2.14 → 2.14,security
moving to real milestones...
Whiteboard: 2.14,security → security
Target Milestone: --- → Bugzilla 2.14
The change itself is simple. Per it merely
requires us to replace:

Content-type: text/html

... with:

Content-Type: text/html; charset=ISO-8859-1

... everywhere it appears in the code.

(The name "content-type" is case-insensitive.  I capitalized the "T" in it
because that seems to be the convention in the HTTP/1.1 spec.)

However, unfortunately that means touching a large portion of the code.  Are
there best practices that should be applied here to make the check-in as smooth
as possible?  I am thinking in particular of how to make sure we break the
minimum number of existing patches with a check-in of this scope.

An alternative solution is to use the approach recommended in the CERT advisory
of specifying the character set in the HTML HEAD section like so:

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

This isn't quite as elegant but has the advantage of touching only four files:
changepassword.cgi,, buglist.cgi, and reports.cgi.


17 years ago

Comment 4

17 years ago
i vote for #2 for now.  myk can i impose on you to make a patch?  i'm still
working my way through my list.
Assignee: tara → myk

Comment 5

17 years ago
myk says dawn wants this one...
Assignee: myk → endico

Comment 6

17 years ago
I think we should go with http headers instead. There is a bug with both
netscape 4 and mozilla (and others?) which causes pages with <meta ... charset>
to load twice.

Also, what do you do with pages with multiple charsets? For instance, when
someone types in some japanese or arabic in a comment.

If you have to do something with those pages besides the normal
charset=ISO-8859-1. then how do you determine which charsets you have?

Whiteboard: security → security code

Comment 7

17 years ago
Much I would like to support this effort, the only way this makes sense
is for the charset to be multilingual, e.g. UTF-8, which then 
can support virtually all language scripts.  
Whatever method you take, if you insert charset=ISO-8859-1, then you
will be inconveniencing users who need to read data other than 
ISO-8859-1, e.g. people can input Japanese data and because we don't
tag the pages with the charset, you can read them just by having the
charset on the browser side to be in your own language encoding.
The moment you put in a charset tag, or have the server send it,
we will be forcing these users to override the charset if you use
Netscape 6. If you use Communicator, there is nothing you can do.
The charset tag cannot be overridden and non ISO-8859-a content
can be displayed. 

Thus, the proposal is not practical at this point. Move to UTF-8 should be
considered in the near future, but in that case, we need to consider
backend issues.

For these reasons, I recommend against doing this at this time unless
you want Bugzilla to be monolingual and inconvenience all these L10n
projects people who can read the content as well those who count on 
Bugzilla to support display of non-Latin 1 script.

We can discuss alternatives but that would require extra things.
The best thing is to do here is to include this factor in the discussion
for supporting multiple lnaguage scripts better in the future.

Comment 8

17 years ago
> The charset tag cannot be overridden and non ISO-8859-a content
> can be displayed. 


The charset tag cannot be overridden and non ISO-8859-a content
can NOT be displayed. 

So we aren't doing this for 2.14, then?


Comment 10

17 years ago
Kat makes a whole lot of sense.  Despite the potential risk, this really belongs
as part of an overall evaluation as to how we support localization in general. 
In the meantime, a release note might not be out of the question if people want
to make this customization part of their own configuration, and pick the charset
appropriate to the their target audience.  

Reassinging to Matt Barnson and cc-ing Dave Miller.
Assignee: endico → barnboy
Target Milestone: Bugzilla 2.14 → Bugzilla 2.16

Comment 11

17 years ago
Moving back to 2.14.  I am completely mystified as to how I managed to change
the target milestone without noticing.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.14

Comment 12

17 years ago
OK, accepting bug and putting these charset instructions down as part of the
Installation section of the Bugzilla Guide.  Once I'm done, should I reassign
this back to Dawn for further looks as we try to support better
internationalization, or go ahead and resolve it fixed since it's documented?
Dawn, there's comments directed to you on here, and you weren't cc'd.

Comment 14

17 years ago
please use the meta. the real one causes netscape0.93beta and i think some 
other versions to crash or fail to load pages. or at least sniff for old 
browsers and provide them the simple text/html

Comment 15

17 years ago
I don't have this in the Guide yet, but I'll work on it over this weekend.

Comment 16

17 years ago
Documented, checked in.  Marking resolved.  We may wish to address this some 
time in the future, but I'm sure it will be covered by any other 
internationalization efforts.
Last Resolved: 17 years ago
Resolution: --- → FIXED
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
Component: Bugzilla-General → Documentation
anyone still interested in this topic, please see bug 126266 and weigh in there.
We appear to have a paramaterized solution for this in the works. :)
*** Bug 289147 has been marked as a duplicate of this bug. ***
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.