On 18 Oct 2008, at 20:22, William A. Rowe, Jr. wrote:
Comments inline; You painted this situation today with an overly broad brush, there are some remaining issues but they are much narrower than you identifybelow...
You seem to have summed up the issues. Just to expand with a practical point.
So what does the HTML spec have to say? The <FORM > submission element does include the accept-charset attribute, perhaps that is what you are looking for? Otherwise, if the user agents don't observe RFC 2388 thenyou should really take that up with the user agent vendors.
This became a (relatively) frequent complaint with mod_proxy_html 2.x, and
one of the motivations behind the updates in 3.0.The issue: libxml2 uses utf-8 internally. When presented with a different charset, mod_proxy_html has to convert (or setup the parser to convert internally), and
mod_proxy_html 2.x always generates output as utf-8. The complaint was that when this happens to a page containing a <form>, it would cause browsers to submit the form data as utf-8, which in turnscrewed up some peoples applications. It's not a problem I've had myself, but a few users made the case coherently, so I felt compelled to fix it by
enabling the user to specify an output charset of choice.So as you say, there is an issue, but I think this is indeed the extent of it.
-- Nick Kew --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|