Alright, just forget I suggested that. If in front of a html character a
byte above 127 appears (a character outside of 7 bit ASCII), the control
character would get interpreted as part of the same character in utf-8. In
other words: It WILL break.
The suggestion just sounded too good. Back to the
A completely different idea to solve my actual problem:
Someone else suggested to just take out the conversions all together.
I mean, I am converting right back into the encoding I converted from. I
have been assured that no link uses a character above the first 128 (7 bit
ASCII). As far as I know
>
>
> Can you get mod_diagnostics
>> output to track the data running through the filter?
>>
>> I'll try that after lunch. Ask if you want to know anything else. (I can
> for example packet sniff the connection between IE and the proxy, and give
> you the debug output of mod_proxy_html in that con
>
> On 10 Nov 2009, at 08:56, Martin Gerdes wrote:
>
> First, how slow is slow? Time from pushing the send button until the new
>> webpage is loaded rises from 10.6 to 103 seconds.
>>
>
> 10.6 is already horrendously slow (unless perhaps it's a 20-year-old PC),
> which leads me to wonder what you'
On 10 Nov 2009, at 08:56, Martin Gerdes wrote:
First, how slow is slow? Time from pushing the send button until the
new webpage is loaded rises from 10.6 to 103 seconds.
10.6 is already horrendously slow (unless perhaps it's a 20-year-old
PC),
which leads me to wonder what you're doing.
Alright, xml2enc works, does not crash, and correctly translates UTF8 back
to ISO-8859-1 after it was converted to UTF-8 by mod_proxy_html.
However, activating that translation back to ISO-8859-1 makes the whole
process take up a lot of time, and I have no idea why, so I am asking for
ideas.
First
