Return-Path: 
 <users-return-78129-apmail-httpd-users-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-users-archive@www.apache.org
Received: (qmail 82370 invoked from network); 5 Jan 2008 00:37:27 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 5 Jan 2008 00:37:27 -0000
Received: (qmail 45512 invoked by uid 500); 5 Jan 2008 00:37:06 -0000
Delivered-To: apmail-httpd-users-archive@httpd.apache.org
Received: (qmail 45208 invoked by uid 500); 5 Jan 2008 00:37:06 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help: <mailto:users-help@httpd.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@httpd.apache.org>
List-Post: <mailto:users@httpd.apache.org>
List-Id: <users.httpd.apache.org>
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 45196 invoked by uid 99); 5 Jan 2008 00:37:06 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 16:37:06 -0800
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [68.230.241.44] (HELO fed1rmmtao102.cox.net) (68.230.241.44)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Jan 2008 00:36:40 +0000
Received: from fed1rmimpo02.cox.net ([70.169.32.72])
          by fed1rmmtao102.cox.net
          (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP
          id
 <20080105003643.DFAR24689.fed1rmmtao102.cox.net@fed1rmimpo02.cox.net>
          for <users@httpd.apache.org>; Fri, 4 Jan 2008 19:36:43 -0500
Received: from Trogdor.crimson-dragon.com ([68.7.67.206])
	by fed1rmimpo02.cox.net with bizsmtp
	id ZCcn1Y00U4T0pno0000000; Fri, 04 Jan 2008 19:36:48 -0500
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Jan 2008 16:36:40 -0800
To: users@httpd.apache.org
From: Dragon <dragon@crimson-dragon.com>
In-Reply-To: <1199485251.4087.30.camel@localhost.localdomain>
References: <1199485251.4087.30.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Message-Id: 
 <20080105003643.DFAR24689.fed1rmmtao102.cox.net@fed1rmimpo02.cox.net>
X-Virus-Checked: Checked by ClamAV on apache.org
Subject: Re: [users@httpd] problem with posted data in UTF-8 and
  reverse proxy

Scott Douglass did speak thusly:
>Hi,
>
>Please excuse the Tomcat references below, my question is actually about
>the HTTPD reverse proxy feature.
>
>I have a web app that, when viewed by hitting the Tomcat 6.0.14 server
>it runs on handles the input of multi-byte characters using the UTF-8
>encoding. The application is a web mail client, and it uses HTTP POST to
>send the fields of the message composer window to the server.
>
>When I put this exact same tomcat/webapp behind the HTTPD 2.2.6 reverse
>proxy, the Chinese characters POST'd via the composer window gets some
>other encoding than UTF-8. The end result is that when the user views
>the result (say they send the mail message to themselves) the Chinese
>characters are not decoded correctly.
>
>For example, I type this into a textarea for the body of the message in
>the composing form:
>
>=E4=BD =E5=A5=BD =E5=93=88=E5=93=88 =E5=AD=94=E6=AD=87
>
>When I post this directly to tomcat/webapp, I see it again when I
>recieve the e-mail a few seconds later (Tomcat has a /* servlet filter
>that forces UTF-8 encoding on all request and response parameters, also
>all JSPs have <%@ page contentType=3D"text/html; charset=3DUTF-8" %>, and
>also <meta HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html;=
 charset=3DUTF-8">
>and tomcat container definition has URIEncoding=3D"UTF-8"...)
>
>When I post through the HTTPD 2.2.6 reverse proxy, the end result
>appears like:
>
>=C3=A4=C2=BD =C3=A5=C2=A5=C2=BD =C3=A5=E2=80=9C=88=C3=A5=E2=80=9C=88=
 =C3=A5=C2=AD=E2=80=9D=C3=A6=AD=87
>=E2=80=A1
>
>I've tried as many work arounds as I could search/find/think of
>including:
>
>AddDefaultCharset none
>
>vs.
>
>AddDefaultCharset UTF-8
>
>Neither of these solves the problem.
>
>Has anyone ever encountered this before? I am happy with the HTTPD as a
>reverse proxy other than this encoding issue, and I'm using HTTPD for a
>bunch of other functions as well (WebDAV, virtual hosting, subversion
>repository, etc.) So, I prefer to solve this reverse proxy problem
>rather than use some other proxy server.
---------------- End original message. ---------------------

You are going to need to provide more=20
information, there simply isn't enough here to=20
know how these requests are being processed when=20
proxied. In particular, how do you have the=20
reverse proxy configured in your httpd.conf file?

Which proxy modules are you using, etc.?

Having those configuration directives will allow=20
somebody (probably not me, I'm an amateur at this=20
stuff) to decipher what is happening.



Dragon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org