| 2006-04-21 06:38:34 |
Björn Tillenius |
bug |
|
|
added bug |
| 2006-04-21 06:49:15 |
Björn Tillenius |
description |
Many of our pages require utf-8, and if a browser says that it doesn't accept utf-8, Launchpad will crash badly, producing an OOPS like OOPS-109C83.
I think there are two ways this can be solved.
* Return some HTTP response code, I can't remember which, but
I'm quite sure there is a special one for encoding errors.
* Encode the page in utf-8 anyway, letting the client handle
the error handling
The latter is probably the most acceptable solution, since most clients do handle utf-8 even though they don't say it, and it saves them from seeing an error page.
We do have to consider the encoding of the returned data though. If we send the data as ISO-8859-1, the browser will most likely send POST data as ISO-8859-1 as well. What happens if the user tries to POST non-ISO-8859-1 characters. In which encoding will the POST data be sent if the browser says utf-8 isn't acceptable, but we encode the page in utf-8 anyway? |
Many of our pages require utf-8, and if a browser says that it doesn't accept utf-8, Launchpad will crash badly, producing an OOPS like OOPS-109C83.
I think there are two ways this can be solved.
* Return some HTTP response code, I can't remember which, but
I'm quite sure there is a special one for encoding errors.
* Encode the page in utf-8 anyway, letting the client handle
the error handling
The latter is probably the most acceptable solution, since most clients do handle utf-8 even though they don't say it, and it saves them from seeing an error page.
We do have to consider the encoding of the returned data though. If we send the data as ISO-8859-1, the browser will most likely send POST data as ISO-8859-1 as well. What happens if the user tries to POST non-ISO-8859-1 characters. In which encoding will the POST data be sent if the browser says utf-8 isn't acceptable, but we encode the page in utf-8 anyway?
This is a bug in Zope, and has been reported as http://www.zope.org/Collectors/Zope3-dev/588. |
|
| 2006-04-21 06:51:46 |
Björn Tillenius |
title |
Launchpad crashes if badly if the client says it doesn't accept 'utf-8' |
Launchpad crashes badly if the client says it doesn't accept 'utf-8' |
|
| 2006-04-21 07:09:24 |
Björn Tillenius |
description |
Many of our pages require utf-8, and if a browser says that it doesn't accept utf-8, Launchpad will crash badly, producing an OOPS like OOPS-109C83.
I think there are two ways this can be solved.
* Return some HTTP response code, I can't remember which, but
I'm quite sure there is a special one for encoding errors.
* Encode the page in utf-8 anyway, letting the client handle
the error handling
The latter is probably the most acceptable solution, since most clients do handle utf-8 even though they don't say it, and it saves them from seeing an error page.
We do have to consider the encoding of the returned data though. If we send the data as ISO-8859-1, the browser will most likely send POST data as ISO-8859-1 as well. What happens if the user tries to POST non-ISO-8859-1 characters. In which encoding will the POST data be sent if the browser says utf-8 isn't acceptable, but we encode the page in utf-8 anyway?
This is a bug in Zope, and has been reported as http://www.zope.org/Collectors/Zope3-dev/588. |
Many of our pages require utf-8, and if a browser says that it doesn't accept utf-8, Launchpad will crash badly, producing an OOPS like OOPS-109C83.
I can think of tree ways of solving this:
* Return some HTTP response code, I can't remember which, but
I'm quite sure there is a special one for encoding errors.
* Encode the page in utf-8 anyway, letting the client handle
the error handling
* Encode the page in a charset the browser accepts, replacing
all unencodable characters with '?' or something like that.
The latter is probably the most acceptable solution, since most clients do handle utf-8 even though they don't say it, and it saves them from seeing an error page.
We do have to consider the encoding of the returned data though. If we send the data as ISO-8859-1, the browser will most likely send POST data as ISO-8859-1 as well. What happens if the user tries to POST non-ISO-8859-1 characters. In which encoding will the POST data be sent if the browser says utf-8 isn't acceptable, but we encode the page in utf-8 anyway?
This is a bug in Zope, and has been reported as http://www.zope.org/Collectors/Zope3-dev/588. |
|
| 2006-05-08 21:37:38 |
Diogo Matsubara |
launchpad: status |
Unconfirmed |
Confirmed |
|
| 2006-05-08 21:37:38 |
Diogo Matsubara |
launchpad: statusexplanation |
|
|
|
| 2006-06-02 16:45:22 |
Björn Tillenius |
launchpad: assignee |
|
bjornt |
|
| 2006-07-13 12:12:35 |
Björn Tillenius |
launchpad: importance |
Medium |
High |
|
| 2006-07-14 14:48:56 |
Björn Tillenius |
launchpad: status |
Confirmed |
In Progress |
|
| 2006-07-14 14:48:56 |
Björn Tillenius |
launchpad: statusexplanation |
|
A fix is in the review queue. |
|
| 2006-07-19 18:39:40 |
Diogo Matsubara |
launchpad: status |
In Progress |
Fix Committed |
|
| 2006-07-19 18:39:40 |
Diogo Matsubara |
launchpad: statusexplanation |
A fix is in the review queue. |
|
|
| 2006-08-03 10:28:43 |
Björn Tillenius |
launchpad: status |
Fix Committed |
Fix Released |
|
