to prevent untrusted content on bugzilla from executing possibly malicious javascript code, each page should include a charset at the top. see http://www.cert.org/tech_tips/malicious_code_mitigation.html/#3

moving to real milestones...

The change itself is simple. Per http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 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, CGI.pl, buglist.cgi, and reports.cgi.

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.

myk says dawn wants this one...

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? momoi?

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.

> The charset tag cannot be overridden and non ISO-8859-a content > can be displayed. Correction: 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? Gerv

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.

Moving back to 2.14. I am completely mystified as to how I managed to change the target milestone without noticing.

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.

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

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

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.

Moving to Bugzilla product

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. ***