[MAGNOLIA-1512] Request charset should be set before any req.getParameter call Created: 08/May/07 Updated: 23/Jan/13 Resolved: 14/May/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | None |
| Fix Version/s: | 3.1 M2 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Magnolia International |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
At the moment, the request charset is set using Aggregator.getExtension(), which in turns uses Context.getAttribute. Since the WebContextImpl implementation of getAttribute calls getParameter in case the attribute does not exist on the request, thus making the setCharacterSet call useless - and preventing parameters to be parsed properly (indeed, the container will parse them on the first call to getParam*() with a default encoding - iso-8859-1 in the case of tomcat) We might solve this by making the Aggregator.getExtension method (and associated) just using the context attribute - which have to be set previously, for instance by a new filter that has yet to be created. |
| Comments |
| Comment by Magnolia International [ 10/May/07 ] |
|
A new filter will (partially) initiliase the Aggregator instance (which will be exposed in the context once |
| Comment by Magnolia International [ 10/May/07 ] |
|
Actually, with Normally, the browser should send a character set in the request, and if so, the container SHOULD take into account, only falling back to iso-8859-1 if that's not the case. It is still unclear what tomcat really does, but I've noticed my firefox does not send any charset header in its requests, even if the originating page has meta tags, form enctype attribute etc ... |
| Comment by Magnolia International [ 11/May/07 ] |
|
done |
| Comment by Magnolia International [ 11/May/07 ] |
|
reopening: make sure we don't override any existing charset... there actually ARE ways to make the browser send it! VERY ugly but works: |
| Comment by Magnolia International [ 14/May/07 ] |
|
fixed: not overriding the request encoding if already set. however, the |
| Comment by Philipp Bracher [ 15/May/07 ] |
|
You could introduce a configurable force encoding flag. |
| Comment by Magnolia International [ 15/May/07 ] |
|
It is forced, in a sense, now: the request's char.encoding is going to depend on the requested'uri extension/mimetype. |