Closed
Bug 38856
Opened 24 years ago
Closed 23 years ago
all bugzilla pages should specify charset
Categories
(Bugzilla :: Documentation, defect, P3)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.14
People
(Reporter: jruderman, Assigned: barnboy)
References
()
Details
(Whiteboard: security code)
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
Updated•24 years ago
|
Whiteboard: 2.14
Updated•24 years ago
|
Whiteboard: 2.14 → 2.14,security
Comment 1•24 years ago
|
||
moving to real milestones...
Whiteboard: 2.14,security → security
Target Milestone: --- → Bugzilla 2.14
Comment 2•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
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.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 4•23 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
Status: ASSIGNED → NEW
Comment 6•23 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? momoi?
Status: NEW → ASSIGNED
Updated•23 years ago
|
Whiteboard: security → security code
Comment 7•23 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•23 years ago
|
||
> 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.
Comment 9•23 years ago
|
||
So we aren't doing this for 2.14, then? Gerv
Comment 10•23 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
Status: ASSIGNED → NEW
Target Milestone: Bugzilla 2.14 → Bugzilla 2.16
Comment 11•23 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
Assignee | ||
Comment 12•23 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?
Status: NEW → ASSIGNED
Comment 13•23 years ago
|
||
Dawn, there's comments directed to you on here, and you weren't cc'd.
Comment 14•23 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
Assignee | ||
Comment 15•23 years ago
|
||
I don't have this in the Guide yet, but I'll work on it over this weekend.
Assignee | ||
Comment 16•23 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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 17•23 years ago
|
||
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
Updated•23 years ago
|
Component: Bugzilla-General → Documentation
Comment 18•23 years ago
|
||
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. :)
Comment 19•19 years ago
|
||
*** Bug 289147 has been marked as a duplicate of this bug. ***
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•