View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000979 | Main CAcert Website | public | 2011-09-04 23:17 | 2021-08-25 13:35 | |
| Reporter | NEOatNHNG | Assigned To | BenBE | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | needs feedback | Resolution | open | ||
| Platform | Main CAcert Website | OS | N/A | OS Version | stable |
| Summary | 0000979: HTML <meta> tag states charset=utf-8 on some pages when it is not | ||||
| Description | There are some pages (known: account.php, maybe more) where the HTML meta tag declares the Content-Type to be "text/html; charset=utf-8" when in fact we always use ISO-8859-1 (aka latin1) as encoding (at least for values from the data base). This error doesn't show because the web server explicitly sets a content type header of it's own and therefore overwrites the setting but it's wrong nevertheless. | ||||
| Additional Information | Maybe remove the meta tag alltogether because it is not in effect anyway? | ||||
| Tags | No tags attached. | ||||
| Reviewed by | NEOatNHNG | ||||
| Test Instructions | |||||
|
|
Wouldn't it be much better to use UTF-8 everywhere (I know that this is not possible with the current codebase). I see the problem that we are not able to handle non-Latin character sets if we stick with ISO-8859-1. Cyrillic and asian character sets are use by a huge share of the world population and we should not force everyone to transliterate their names to latin characters. |
|
|
Yes, transitioning to UTF-8 would be great but is very complicated with the current code base, as you mentioned. Non-latin1 characters can be entered though. They are escaped as HTML entities by the browser AFAIK. For now we should at least fix our software so that latin1 is handled correctly we then have to do a big master plan how to move on. |
|
|
And this HTML entities are causing problems with generating certificates/signing PGP keys for people with diffrent-than-english-or-german charset. |
|
|
Apparently the account_stuff.php was the only relevant part where this would cause problems. Fixed. Please test and do a second review. |
|
|
I still see some forms which are posted utf-8 when the pages themselves are latin1. While by the standard this is perfectly valid it usually causes problems with some browsers when they need to decide which of various conflicting charset values to use - usually they will use the wrong one. Thus we should convert the codebase to UTF-8 and tell so in the returned documents. Given the numerous occations we currently have to do charset conversions it would be much simpler if those would be reduced to basically Charset Normalization and Escaping. Review NACK. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-09-04 23:17 | NEOatNHNG | New Issue | |
| 2011-09-05 08:38 | jandd | Note Added: 0002403 | |
| 2011-09-05 13:58 | NEOatNHNG | Note Added: 0002408 | |
| 2011-09-05 14:00 | NEOatNHNG | Note Edited: 0002408 | |
| 2011-10-25 01:14 | MarekMazur | Note Added: 0002638 | |
| 2012-12-23 07:45 | Werner Dworak | Relationship added | related to 0001097 |
| 2014-03-11 23:50 | NEOatNHNG | Source_changeset_attached | => cacert-devel testserver-stable 94514eed |
| 2014-03-11 23:50 | NEOatNHNG | Source_changeset_attached | => cacert-devel testserver-stable b05b43a8 |
| 2014-03-11 23:55 | NEOatNHNG | Reviewed by | => NEOatNHNG |
| 2014-03-11 23:55 | NEOatNHNG | Note Added: 0004637 | |
| 2014-03-11 23:55 | NEOatNHNG | Status | new => needs review & testing |
| 2014-03-27 07:19 | BenBE | Note Added: 0004687 | |
| 2014-03-27 07:20 | BenBE | Assigned To | => BenBE |
| 2014-03-27 07:20 | BenBE | Status | needs review & testing => needs feedback |
| 2021-08-25 13:35 | bdmc | Relationship added | related to 0000769 |
