You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2005/05/02 02:04:06 UTC
Re: [1.3 PATCH] rework suppress-error-charset feature
On 4/29/05, Jeff Trawick <tr...@gmail.com> wrote:
> On 4/29/05, Jim Jagielski <ji...@jagunet.com> wrote:
> > +1 from me :)
> >
> > How appropriate would a 2.0/2.1 patch be as well?
>
> You tell me. I'm certainly willing to work up a 2.1 patch.
>
> I have to confess to ignorance about the scope of the problem.
I found a description of the problem:
> When Apache issues a redirect in response to a client request, the response
> includes some actual text to be displayed in case the client can't (or doesn't)
> automatically follow the redirection. Apache ordinarily labels this text according
> to the character set which it uses, which is ISO-8859-1.
>
> However, if the redirection is to a page that uses a different character set, some
> broken browser versions will try to use the character set from the redirection text
> rather than the actual page. This can result in Greek, for instance, being
> incorrectly rendered.
Re: [1.3 PATCH] rework suppress-error-charset feature
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/11/05, Jeff Trawick <tr...@gmail.com> wrote:
> Funny. I just heard from a Japanese user with an issue with this path
> too, but this time with 2.0. A third-party module is generating a
> custom error response and specifies a Japanese codepage in the
> generated HTML. But it goes through this error response code and
> picks up the "charset=iso-8859-1" attribute. This particular
> situation isn't tied to a particular browser, but I'll still use the
> suppress-error-charset solution so that it matches 1.3. The user can
> use SetEnvIf with Request_URI to match all requests.
Not funny: 1.3.x and 2.x docs say that Apache >= 2.0.40 already has
this feature. I can't find that the trivial code was ever committed
though. Related PR: 31274.
Re: [1.3 PATCH] rework suppress-error-charset feature
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/2/05, Jeff Trawick <tr...@gmail.com> wrote:
> On 5/2/05, Rici Lake <ri...@ricilake.net> wrote:
> >
> > If the action is required to compensate for a browser bug, wouldn't it
> > be better to leave it as an environment variable and set it with
> > BrowserMatch?
>
> You're absolutely right. I put the blinders on to environment
> variables when I saw that mod_env didn't do anything until the fixup
> hook, which is too late for processing of Redirect directives. But
> mod_setenvif does its work sooner and is the proper solution.
Funny. I just heard from a Japanese user with an issue with this path
too, but this time with 2.0. A third-party module is generating a
custom error response and specifies a Japanese codepage in the
generated HTML. But it goes through this error response code and
picks up the "charset=iso-8859-1" attribute. This particular
situation isn't tied to a particular browser, but I'll still use the
suppress-error-charset solution so that it matches 1.3. The user can
use SetEnvIf with Request_URI to match all requests.
Re: [1.3 PATCH] rework suppress-error-charset feature
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/2/05, Rici Lake <ri...@ricilake.net> wrote:
>
> On 1-May-05, at 7:04 PM, Jeff Trawick wrote:
>
> > I found a description of the problem:
> >
> >> When Apache issues a redirect in response to a client request, the
> >> response
> >> includes some actual text to be displayed in case the client can't
> >> (or doesn't)
> >> automatically follow the redirection. Apache ordinarily labels this
> >> text according
> >> to the character set which it uses, which is ISO-8859-1.
> >>
> >> However, if the redirection is to a page that uses a different
> >> character set, some
> >> broken browser versions will try to use the character set from the
> >> redirection text
> >> rather than the actual page. This can result in Greek, for instance,
> >> being
> >> incorrectly rendered.
>
> If the action is required to compensate for a browser bug, wouldn't it
> be better to leave it as an environment variable and set it with
> BrowserMatch?
You're absolutely right. I put the blinders on to environment
variables when I saw that mod_env didn't do anything until the fixup
hook, which is too late for processing of Redirect directives. But
mod_setenvif does its work sooner and is the proper solution.
Thanks!
Re: [1.3 PATCH] rework suppress-error-charset feature
Posted by Rici Lake <ri...@ricilake.net>.
On 1-May-05, at 7:04 PM, Jeff Trawick wrote:
> I found a description of the problem:
>
>> When Apache issues a redirect in response to a client request, the
>> response
>> includes some actual text to be displayed in case the client can't
>> (or doesn't)
>> automatically follow the redirection. Apache ordinarily labels this
>> text according
>> to the character set which it uses, which is ISO-8859-1.
>>
>> However, if the redirection is to a page that uses a different
>> character set, some
>> broken browser versions will try to use the character set from the
>> redirection text
>> rather than the actual page. This can result in Greek, for instance,
>> being
>> incorrectly rendered.
If the action is required to compensate for a browser bug, wouldn't it
be better to leave it as an environment variable and set it with
BrowserMatch?