You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Böckling <Mi...@dmc.de> on 2007/09/06 15:48:40 UTC

POST data lost when switching URL using mod_rewrite and mod_jk

Hi folks!

I Have the following setup:

Apache/2.2.4 
mod_ssl/2.2.4 
mod_jk/1.2.25
mod_rewrite (?)
Apache Tomcat 5.5.23

Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat


This is a Linux machine, and mod_rewrite is used to switch to SSL on certain URLs.

Problem: the POST data is lost whenever a form on a http page sends data to a page that gets its URL rewritten to https.
This goes as folllows:

http page => form post to http url => rewrite url to https, switch to SSL => display https url

No data arrives when using POST!
I know there is a bug that limits the maximum post size to x KB, but in my case, the post data is a just a few text fields.
Any idea as to why this happens?

Regards,


Michael


-- 
Michael Böckling
Java Engineer
dmc digital media center GmbH 
Rommelstraße 11 
70376 Stuttgart (Germany) 
Telefon: +49 711 601747-0
Telefax: +49 711 601747-141 
E-Mail: Michael.Boeckling@dmc.de 
Internet: www.dmc.de 

Handelsregister: AG Stuttgart HRB 18974
Geschäftsführer: Andreas Magg, Daniel Rebhorn, Andreas Schwend

---------------------------------------------
"Open Source ist reif für ECM" zeigt Ihnen neue und innovative Lösungswege sowie Best Practices aus dem Bereich Enterprise Content Management. Besuchen Sie die ECM-Vortragsreihe bei dmc!

Nächste Veranstaltung:
20. September 2007, 15-18.30 Uhr: "Digitaler Rechnungsein- und ausgang. Was ist möglich? Was ist erlaubt? - Automatische Verarbeitung des Rechnungseingangs und digitale Signierung von Dokumenten beim Versand von elektronischen Dokumenten."
Veranstaltungsort: Römerkastell, 70376 Stuttgart 

Melden Sie sich unter www.dmc.de/ecm an oder besuchen Sie uns vom 25.-27.09.07 auf der DMS in Köln: Halle 7, Stand G095!

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by Michael Böckling <Mi...@dmc.de>.
This is great, it seems to work for me!

I just found this page, which describes the issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=34602

In post #16, it is suggested that "RewriteMap esc int:escape" is required to correctly escape the non-query part of the URL.
Is that true?

Thanks for your help,


Michael Böckling


> -----Original Message-----
> From: fredk2 [mailto:fredk2@gmail.com]
> Sent: Thursday, September 06, 2007 7:30 PM
> To: users@tomcat.apache.org
> Subject: RE: POST data lost when switching URL using mod_rewrite and
> mod_jk
> 
> 
> 
> The mod_rewrites encoding can be changed with option 
> 'noescape|NE' (no URI escaping of output) 
> 
> This flag keeps mod_rewrite from applying the usual URI 
> escaping rules to
> the result of a rewrite. Ordinarily, special characters (such 
> as '%', '$',
> ';', and so on) will be escaped into their hexcode equivalents ('%25',
> '%24', and '%3B', respectively); this flag prevents this from 
> being done.
> This allows percent symbols to appear in the output, as in 
> 
> RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE] 
> 
> Rgds, Fred
> 
> 
> Michael Böckling wrote:
> > 
> > 
> >> why aren't you 
> >> switching to https before it gets complicated, i.e. when a 
> simple request 
> >> is coming in, like for the form page itself?
> > 
> > Unfortunately, that is not an option.
> > 
> > 
> >> - is the Location header apache httpd sends back for the 
> >> redirect still 
> >> OK? You can check with a commandline client like e.g. curl.
> >> 
> > 
> > No, here's where the trouble starts. It seems like mod_rewrite can't
> > handle UTF-8 URLs. I used the LiveHTTPHeaders plugin for 
> Firefox, and
> > here's the output:
> > 
> > Original (correct request):
> > GET /lucene/target.jsp?test=%C3%BCberraschung HTTP/1.1
> > 
> > Flawed redirect:
> > Location:
> > http://localhost:778/lucene/target.jsp?test=%25C3%25BCberraschung
> > 
> > As you can see, the % have been encoded again.
> > 
> > What can I do about it?
> > 
> > 
> > Regards,
> > 
> > Michael
> > 
> > 
> > 
> >> - if so, is the second request as decoded by apache OK? The 
> >> access log 
> >> might give an idea about that
> >> 
> >> - if so, is the forwarded request from mod_jk to Tomcat OK 
> >> (JkLogLevel 
> >> debug shows a line ...service... which containes the 
> forwarded URL at 
> >> the end)
> >> 
> >> Regards,
> >> 
> >> Rainer
> >> 
> >> Michael Böckling wrote:
> >> > Ok, that makes it clear to me.
> >> > Thanks for the exhaustive reply!
> >> > 
> >> > Btw., I didn't configure the servers, I'm just trying to 
> >> get my forms data through and understand as much as possible. :-)
> >> > 
> >> > So I switched to GET, but again, I ran into issues, this 
> >> time it is character-encoding related.
> >> > The Tomcats all have URIEncoding="UTF-8" set, and it works 
> >> whithout the rewrite-induced redirect.
> >> > 
> >> > But when redirect is used, the following happens:
> >> > 
> >> > The parameter "führung" becomes "f%C3%BChrung" in my JSPs. 
> >> I did "AddDefaultEncoding UTF-8" in my Apache config, that 
> >> doesn't help. Is there a configuration option for mod_rewrite 
> >> or mod_jk that I have to set to make it work? I tried the 
> >> "ForwardURIxxx" options on my mod_jk, but they didn't 
> help. Any Ideas?
> >> > 
> >> > Thanks a lot for the help so far!
> >> > 
> >> > Regards,
> >> > 
> >> > 
> >> > Michael
> >> > 
> >> > 
> >> > 
> >> >> -----Original Message-----
> >> >> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> >> >> Sent: Thursday, September 06, 2007 4:35 PM
> >> >> To: Tomcat Users List
> >> >> Subject: Re: POST data lost when switching URL using 
> >> mod_rewrite and
> >> >> mod_jk
> >> >>
> >> >>
> >> >> Example from
> >> >>
> >> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> >> >>
> >> >> 10.3.2 301 Moved Permanently
> >> >>
> >> >> The requested resource has been assigned a new permanent 
> >> URI and any 
> >> >> future references to this resource SHOULD use one of the 
> >> >> returned URIs. 
> >> >> Clients with link editing capabilities ought to 
> >> automatically re-link 
> >> >> references to the Request-URI to one or more of the new 
> references 
> >> >> returned by the server, where possible. This response 
> is cacheable 
> >> >> unless indicated otherwise.
> >> >>
> >> >> The new permanent URI SHOULD be given by the Location 
> field in the 
> >> >> response. Unless the request method was HEAD, the entity of 
> >> >> the response 
> >> >> SHOULD contain a short hypertext note with a hyperlink to the 
> >> >> new URI(s).
> >> >>
> >> >> If the 301 status code is received in response to a request 
> >> >> other than 
> >> >> GET or HEAD, the user agent MUST NOT automatically redirect 
> >> >> the request 
> >> >> unless it can be confirmed by the user, since this might 
> >> change the 
> >> >> conditions under which the request was issued.
> >> >>
> >> >>        Note: When automatically redirecting a POST request after
> >> >>        receiving a 301 status code, some existing HTTP/1.0 
> >> user agents
> >> >>        will erroneously change it into a GET request.
> >> >>
> >> >> So if you are using HTTp Redirect, check your Apache 
> >> access log. It's 
> >> >> likely you will notice, that the browser switched from a POST 
> >> >> to a GET 
> >> >> during the redirect and the POST Body isn't send by the 
> >> >> Browser. Nothing 
> >> >> we could do in this case on the server side.
> >> >>
> >> >> You should try to identify a GET which sits before the 
> >> POST in your 
> >> >> clickstream and do the redirect already there (like 
> e.g. when the 
> >> >> browser tries to retrieve the empty form before it tries 
> >> to send the 
> >> >> contents).
> >> >>
> >> >> Regards,
> >> >>
> >> >> Rainer
> >> >>
> >> >> Michael Böckling wrote:
> >> >>> Hi folks!
> >> >>>
> >> >>> I Have the following setup:
> >> >>>
> >> >>> Apache/2.2.4 
> >> >>> mod_ssl/2.2.4 
> >> >>> mod_jk/1.2.25
> >> >>> mod_rewrite (?)
> >> >>> Apache Tomcat 5.5.23
> >> >>>
> >> >>> Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat
> >> >>>
> >> >>>
> >> >>> This is a Linux machine, and mod_rewrite is used to switch 
> >> >> to SSL on certain URLs.
> >> >>> Problem: the POST data is lost whenever a form on a http 
> >> >> page sends data to a page that gets its URL rewritten to https.
> >> >>> This goes as folllows:
> >> >>>
> >> >>> http page => form post to http url => rewrite url to https, 
> >> >> switch to SSL => display https url
> >> >>> No data arrives when using POST!
> >> >>> I know there is a bug that limits the maximum post size to 
> >> >> x KB, but in my case, the post data is a just a few text fields.
> >> >>> Any idea as to why this happens?
> >> >>>
> >> >>> Regards,
> >> 
> >> 
> ---------------------------------------------------------------------
> >> To start a new topic, e-mail: users@tomcat.apache.org
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >> 
> >> 
> > 
> > 
> ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> > 
> > 
> > 
> 
> -- 
> View this message in context: 
http://www.nabble.com/POST-data-lost-when-switching-URL-using-mod_rewrite-and-mod_jk-tf4392318.html#a12527470
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by fredk2 <fr...@gmail.com>.
The mod_rewrites encoding can be changed with option 
'noescape|NE' (no URI escaping of output) 

This flag keeps mod_rewrite from applying the usual URI escaping rules to
the result of a rewrite. Ordinarily, special characters (such as '%', '$',
';', and so on) will be escaped into their hexcode equivalents ('%25',
'%24', and '%3B', respectively); this flag prevents this from being done.
This allows percent symbols to appear in the output, as in 

RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE] 

Rgds, Fred


Michael Böckling wrote:
> 
> 
>> why aren't you 
>> switching to https before it gets complicated, i.e. when a simple request 
>> is coming in, like for the form page itself?
> 
> Unfortunately, that is not an option.
> 
> 
>> - is the Location header apache httpd sends back for the 
>> redirect still 
>> OK? You can check with a commandline client like e.g. curl.
>> 
> 
> No, here's where the trouble starts. It seems like mod_rewrite can't
> handle UTF-8 URLs. I used the LiveHTTPHeaders plugin for Firefox, and
> here's the output:
> 
> Original (correct request):
> GET /lucene/target.jsp?test=%C3%BCberraschung HTTP/1.1
> 
> Flawed redirect:
> Location:
> http://localhost:778/lucene/target.jsp?test=%25C3%25BCberraschung
> 
> As you can see, the % have been encoded again.
> 
> What can I do about it?
> 
> 
> Regards,
> 
> Michael
> 
> 
> 
>> - if so, is the second request as decoded by apache OK? The 
>> access log 
>> might give an idea about that
>> 
>> - if so, is the forwarded request from mod_jk to Tomcat OK 
>> (JkLogLevel 
>> debug shows a line ...service... which containes the forwarded URL at 
>> the end)
>> 
>> Regards,
>> 
>> Rainer
>> 
>> Michael Böckling wrote:
>> > Ok, that makes it clear to me.
>> > Thanks for the exhaustive reply!
>> > 
>> > Btw., I didn't configure the servers, I'm just trying to 
>> get my forms data through and understand as much as possible. :-)
>> > 
>> > So I switched to GET, but again, I ran into issues, this 
>> time it is character-encoding related.
>> > The Tomcats all have URIEncoding="UTF-8" set, and it works 
>> whithout the rewrite-induced redirect.
>> > 
>> > But when redirect is used, the following happens:
>> > 
>> > The parameter "führung" becomes "f%C3%BChrung" in my JSPs. 
>> I did "AddDefaultEncoding UTF-8" in my Apache config, that 
>> doesn't help. Is there a configuration option for mod_rewrite 
>> or mod_jk that I have to set to make it work? I tried the 
>> "ForwardURIxxx" options on my mod_jk, but they didn't help. Any Ideas?
>> > 
>> > Thanks a lot for the help so far!
>> > 
>> > Regards,
>> > 
>> > 
>> > Michael
>> > 
>> > 
>> > 
>> >> -----Original Message-----
>> >> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
>> >> Sent: Thursday, September 06, 2007 4:35 PM
>> >> To: Tomcat Users List
>> >> Subject: Re: POST data lost when switching URL using 
>> mod_rewrite and
>> >> mod_jk
>> >>
>> >>
>> >> Example from
>> >>
>> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>> >>
>> >> 10.3.2 301 Moved Permanently
>> >>
>> >> The requested resource has been assigned a new permanent 
>> URI and any 
>> >> future references to this resource SHOULD use one of the 
>> >> returned URIs. 
>> >> Clients with link editing capabilities ought to 
>> automatically re-link 
>> >> references to the Request-URI to one or more of the new references 
>> >> returned by the server, where possible. This response is cacheable 
>> >> unless indicated otherwise.
>> >>
>> >> The new permanent URI SHOULD be given by the Location field in the 
>> >> response. Unless the request method was HEAD, the entity of 
>> >> the response 
>> >> SHOULD contain a short hypertext note with a hyperlink to the 
>> >> new URI(s).
>> >>
>> >> If the 301 status code is received in response to a request 
>> >> other than 
>> >> GET or HEAD, the user agent MUST NOT automatically redirect 
>> >> the request 
>> >> unless it can be confirmed by the user, since this might 
>> change the 
>> >> conditions under which the request was issued.
>> >>
>> >>        Note: When automatically redirecting a POST request after
>> >>        receiving a 301 status code, some existing HTTP/1.0 
>> user agents
>> >>        will erroneously change it into a GET request.
>> >>
>> >> So if you are using HTTp Redirect, check your Apache 
>> access log. It's 
>> >> likely you will notice, that the browser switched from a POST 
>> >> to a GET 
>> >> during the redirect and the POST Body isn't send by the 
>> >> Browser. Nothing 
>> >> we could do in this case on the server side.
>> >>
>> >> You should try to identify a GET which sits before the 
>> POST in your 
>> >> clickstream and do the redirect already there (like e.g. when the 
>> >> browser tries to retrieve the empty form before it tries 
>> to send the 
>> >> contents).
>> >>
>> >> Regards,
>> >>
>> >> Rainer
>> >>
>> >> Michael Böckling wrote:
>> >>> Hi folks!
>> >>>
>> >>> I Have the following setup:
>> >>>
>> >>> Apache/2.2.4 
>> >>> mod_ssl/2.2.4 
>> >>> mod_jk/1.2.25
>> >>> mod_rewrite (?)
>> >>> Apache Tomcat 5.5.23
>> >>>
>> >>> Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat
>> >>>
>> >>>
>> >>> This is a Linux machine, and mod_rewrite is used to switch 
>> >> to SSL on certain URLs.
>> >>> Problem: the POST data is lost whenever a form on a http 
>> >> page sends data to a page that gets its URL rewritten to https.
>> >>> This goes as folllows:
>> >>>
>> >>> http page => form post to http url => rewrite url to https, 
>> >> switch to SSL => display https url
>> >>> No data arrives when using POST!
>> >>> I know there is a bug that limits the maximum post size to 
>> >> x KB, but in my case, the post data is a just a few text fields.
>> >>> Any idea as to why this happens?
>> >>>
>> >>> Regards,
>> 
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/POST-data-lost-when-switching-URL-using-mod_rewrite-and-mod_jk-tf4392318.html#a12527470
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by Michael Böckling <Mi...@dmc.de>.
> why aren't you 
> switching to https before it gets complicated, i.e. when a simple request 
> is coming in, like for the form page itself?

Unfortunately, that is not an option.


> - is the Location header apache httpd sends back for the 
> redirect still 
> OK? You can check with a commandline client like e.g. curl.
> 

No, here's where the trouble starts. It seems like mod_rewrite can't handle UTF-8 URLs. I used the LiveHTTPHeaders plugin for Firefox, and here's the output:

Original (correct request):
GET /lucene/target.jsp?test=%C3%BCberraschung HTTP/1.1

Flawed redirect:
Location: http://localhost:778/lucene/target.jsp?test=%25C3%25BCberraschung

As you can see, the % have been encoded again.

What can I do about it?


Regards,

Michael



> - if so, is the second request as decoded by apache OK? The 
> access log 
> might give an idea about that
> 
> - if so, is the forwarded request from mod_jk to Tomcat OK 
> (JkLogLevel 
> debug shows a line ...service... which containes the forwarded URL at 
> the end)
> 
> Regards,
> 
> Rainer
> 
> Michael Böckling wrote:
> > Ok, that makes it clear to me.
> > Thanks for the exhaustive reply!
> > 
> > Btw., I didn't configure the servers, I'm just trying to 
> get my forms data through and understand as much as possible. :-)
> > 
> > So I switched to GET, but again, I ran into issues, this 
> time it is character-encoding related.
> > The Tomcats all have URIEncoding="UTF-8" set, and it works 
> whithout the rewrite-induced redirect.
> > 
> > But when redirect is used, the following happens:
> > 
> > The parameter "führung" becomes "f%C3%BChrung" in my JSPs. 
> I did "AddDefaultEncoding UTF-8" in my Apache config, that 
> doesn't help. Is there a configuration option for mod_rewrite 
> or mod_jk that I have to set to make it work? I tried the 
> "ForwardURIxxx" options on my mod_jk, but they didn't help. Any Ideas?
> > 
> > Thanks a lot for the help so far!
> > 
> > Regards,
> > 
> > 
> > Michael
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> >> Sent: Thursday, September 06, 2007 4:35 PM
> >> To: Tomcat Users List
> >> Subject: Re: POST data lost when switching URL using 
> mod_rewrite and
> >> mod_jk
> >>
> >>
> >> Example from
> >>
> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> >>
> >> 10.3.2 301 Moved Permanently
> >>
> >> The requested resource has been assigned a new permanent 
> URI and any 
> >> future references to this resource SHOULD use one of the 
> >> returned URIs. 
> >> Clients with link editing capabilities ought to 
> automatically re-link 
> >> references to the Request-URI to one or more of the new references 
> >> returned by the server, where possible. This response is cacheable 
> >> unless indicated otherwise.
> >>
> >> The new permanent URI SHOULD be given by the Location field in the 
> >> response. Unless the request method was HEAD, the entity of 
> >> the response 
> >> SHOULD contain a short hypertext note with a hyperlink to the 
> >> new URI(s).
> >>
> >> If the 301 status code is received in response to a request 
> >> other than 
> >> GET or HEAD, the user agent MUST NOT automatically redirect 
> >> the request 
> >> unless it can be confirmed by the user, since this might 
> change the 
> >> conditions under which the request was issued.
> >>
> >>        Note: When automatically redirecting a POST request after
> >>        receiving a 301 status code, some existing HTTP/1.0 
> user agents
> >>        will erroneously change it into a GET request.
> >>
> >> So if you are using HTTp Redirect, check your Apache 
> access log. It's 
> >> likely you will notice, that the browser switched from a POST 
> >> to a GET 
> >> during the redirect and the POST Body isn't send by the 
> >> Browser. Nothing 
> >> we could do in this case on the server side.
> >>
> >> You should try to identify a GET which sits before the 
> POST in your 
> >> clickstream and do the redirect already there (like e.g. when the 
> >> browser tries to retrieve the empty form before it tries 
> to send the 
> >> contents).
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >> Michael Böckling wrote:
> >>> Hi folks!
> >>>
> >>> I Have the following setup:
> >>>
> >>> Apache/2.2.4 
> >>> mod_ssl/2.2.4 
> >>> mod_jk/1.2.25
> >>> mod_rewrite (?)
> >>> Apache Tomcat 5.5.23
> >>>
> >>> Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat
> >>>
> >>>
> >>> This is a Linux machine, and mod_rewrite is used to switch 
> >> to SSL on certain URLs.
> >>> Problem: the POST data is lost whenever a form on a http 
> >> page sends data to a page that gets its URL rewritten to https.
> >>> This goes as folllows:
> >>>
> >>> http page => form post to http url => rewrite url to https, 
> >> switch to SSL => display https url
> >>> No data arrives when using POST!
> >>> I know there is a bug that limits the maximum post size to 
> >> x KB, but in my case, the post data is a just a few text fields.
> >>> Any idea as to why this happens?
> >>>
> >>> Regards,
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by Rainer Jung <ra...@kippdata.de>.
I know that's not the answer you like: but why aren't you switching to 
https before it gets complicated, i.e. when a simple request is coming 
in, like for the form page itself?

To debug the problem you described, we would have to find out, at which 
stage the problem starts:

- is the Location header apache httpd sends back for the redirect still 
OK? You can check with a commandline client like e.g. curl.

- if so, is the second request as decoded by apache OK? The access log 
might give an idea about that

- if so, is the forwarded request from mod_jk to Tomcat OK (JkLogLevel 
debug shows a line ...service... which containes the forwarded URL at 
the end)

Regards,

Rainer

Michael Böckling wrote:
> Ok, that makes it clear to me.
> Thanks for the exhaustive reply!
> 
> Btw., I didn't configure the servers, I'm just trying to get my forms data through and understand as much as possible. :-)
> 
> So I switched to GET, but again, I ran into issues, this time it is character-encoding related.
> The Tomcats all have URIEncoding="UTF-8" set, and it works whithout the rewrite-induced redirect.
> 
> But when redirect is used, the following happens:
> 
> The parameter "führung" becomes "f%C3%BChrung" in my JSPs. I did "AddDefaultEncoding UTF-8" in my Apache config, that doesn't help. Is there a configuration option for mod_rewrite or mod_jk that I have to set to make it work? I tried the "ForwardURIxxx" options on my mod_jk, but they didn't help. Any Ideas?
> 
> Thanks a lot for the help so far!
> 
> Regards,
> 
> 
> Michael
> 
> 
> 
>> -----Original Message-----
>> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
>> Sent: Thursday, September 06, 2007 4:35 PM
>> To: Tomcat Users List
>> Subject: Re: POST data lost when switching URL using mod_rewrite and
>> mod_jk
>>
>>
>> Example from
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>>
>> 10.3.2 301 Moved Permanently
>>
>> The requested resource has been assigned a new permanent URI and any 
>> future references to this resource SHOULD use one of the 
>> returned URIs. 
>> Clients with link editing capabilities ought to automatically re-link 
>> references to the Request-URI to one or more of the new references 
>> returned by the server, where possible. This response is cacheable 
>> unless indicated otherwise.
>>
>> The new permanent URI SHOULD be given by the Location field in the 
>> response. Unless the request method was HEAD, the entity of 
>> the response 
>> SHOULD contain a short hypertext note with a hyperlink to the 
>> new URI(s).
>>
>> If the 301 status code is received in response to a request 
>> other than 
>> GET or HEAD, the user agent MUST NOT automatically redirect 
>> the request 
>> unless it can be confirmed by the user, since this might change the 
>> conditions under which the request was issued.
>>
>>        Note: When automatically redirecting a POST request after
>>        receiving a 301 status code, some existing HTTP/1.0 user agents
>>        will erroneously change it into a GET request.
>>
>> So if you are using HTTp Redirect, check your Apache access log. It's 
>> likely you will notice, that the browser switched from a POST 
>> to a GET 
>> during the redirect and the POST Body isn't send by the 
>> Browser. Nothing 
>> we could do in this case on the server side.
>>
>> You should try to identify a GET which sits before the POST in your 
>> clickstream and do the redirect already there (like e.g. when the 
>> browser tries to retrieve the empty form before it tries to send the 
>> contents).
>>
>> Regards,
>>
>> Rainer
>>
>> Michael Böckling wrote:
>>> Hi folks!
>>>
>>> I Have the following setup:
>>>
>>> Apache/2.2.4 
>>> mod_ssl/2.2.4 
>>> mod_jk/1.2.25
>>> mod_rewrite (?)
>>> Apache Tomcat 5.5.23
>>>
>>> Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat
>>>
>>>
>>> This is a Linux machine, and mod_rewrite is used to switch 
>> to SSL on certain URLs.
>>> Problem: the POST data is lost whenever a form on a http 
>> page sends data to a page that gets its URL rewritten to https.
>>> This goes as folllows:
>>>
>>> http page => form post to http url => rewrite url to https, 
>> switch to SSL => display https url
>>> No data arrives when using POST!
>>> I know there is a bug that limits the maximum post size to 
>> x KB, but in my case, the post data is a just a few text fields.
>>> Any idea as to why this happens?
>>>
>>> Regards,

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by Michael Böckling <Mi...@dmc.de>.
Ok, that makes it clear to me.
Thanks for the exhaustive reply!

Btw., I didn't configure the servers, I'm just trying to get my forms data through and understand as much as possible. :-)

So I switched to GET, but again, I ran into issues, this time it is character-encoding related.
The Tomcats all have URIEncoding="UTF-8" set, and it works whithout the rewrite-induced redirect.

But when redirect is used, the following happens:

The parameter "führung" becomes "f%C3%BChrung" in my JSPs. I did "AddDefaultEncoding UTF-8" in my Apache config, that doesn't help. Is there a configuration option for mod_rewrite or mod_jk that I have to set to make it work? I tried the "ForwardURIxxx" options on my mod_jk, but they didn't help. Any Ideas?

Thanks a lot for the help so far!

Regards,


Michael



> -----Original Message-----
> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> Sent: Thursday, September 06, 2007 4:35 PM
> To: Tomcat Users List
> Subject: Re: POST data lost when switching URL using mod_rewrite and
> mod_jk
> 
> 
> Example from
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 
> 10.3.2 301 Moved Permanently
> 
> The requested resource has been assigned a new permanent URI and any 
> future references to this resource SHOULD use one of the 
> returned URIs. 
> Clients with link editing capabilities ought to automatically re-link 
> references to the Request-URI to one or more of the new references 
> returned by the server, where possible. This response is cacheable 
> unless indicated otherwise.
> 
> The new permanent URI SHOULD be given by the Location field in the 
> response. Unless the request method was HEAD, the entity of 
> the response 
> SHOULD contain a short hypertext note with a hyperlink to the 
> new URI(s).
> 
> If the 301 status code is received in response to a request 
> other than 
> GET or HEAD, the user agent MUST NOT automatically redirect 
> the request 
> unless it can be confirmed by the user, since this might change the 
> conditions under which the request was issued.
> 
>        Note: When automatically redirecting a POST request after
>        receiving a 301 status code, some existing HTTP/1.0 user agents
>        will erroneously change it into a GET request.
> 
> So if you are using HTTp Redirect, check your Apache access log. It's 
> likely you will notice, that the browser switched from a POST 
> to a GET 
> during the redirect and the POST Body isn't send by the 
> Browser. Nothing 
> we could do in this case on the server side.
> 
> You should try to identify a GET which sits before the POST in your 
> clickstream and do the redirect already there (like e.g. when the 
> browser tries to retrieve the empty form before it tries to send the 
> contents).
> 
> Regards,
> 
> Rainer
> 
> Michael Böckling wrote:
> > Hi folks!
> > 
> > I Have the following setup:
> > 
> > Apache/2.2.4 
> > mod_ssl/2.2.4 
> > mod_jk/1.2.25
> > mod_rewrite (?)
> > Apache Tomcat 5.5.23
> > 
> > Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat
> > 
> > 
> > This is a Linux machine, and mod_rewrite is used to switch 
> to SSL on certain URLs.
> > 
> > Problem: the POST data is lost whenever a form on a http 
> page sends data to a page that gets its URL rewritten to https.
> > This goes as folllows:
> > 
> > http page => form post to http url => rewrite url to https, 
> switch to SSL => display https url
> > 
> > No data arrives when using POST!
> > I know there is a bug that limits the maximum post size to 
> x KB, but in my case, the post data is a just a few text fields.
> > Any idea as to why this happens?
> > 
> > Regards,
> > 
> > 
> > Michael
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by Rainer Jung <ra...@kippdata.de>.
Example from

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any 
future references to this resource SHOULD use one of the returned URIs. 
Clients with link editing capabilities ought to automatically re-link 
references to the Request-URI to one or more of the new references 
returned by the server, where possible. This response is cacheable 
unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the 
response. Unless the request method was HEAD, the entity of the response 
SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than 
GET or HEAD, the user agent MUST NOT automatically redirect the request 
unless it can be confirmed by the user, since this might change the 
conditions under which the request was issued.

       Note: When automatically redirecting a POST request after
       receiving a 301 status code, some existing HTTP/1.0 user agents
       will erroneously change it into a GET request.

So if you are using HTTp Redirect, check your Apache access log. It's 
likely you will notice, that the browser switched from a POST to a GET 
during the redirect and the POST Body isn't send by the Browser. Nothing 
we could do in this case on the server side.

You should try to identify a GET which sits before the POST in your 
clickstream and do the redirect already there (like e.g. when the 
browser tries to retrieve the empty form before it tries to send the 
contents).

Regards,

Rainer

Michael Böckling wrote:
> Hi folks!
> 
> I Have the following setup:
> 
> Apache/2.2.4 
> mod_ssl/2.2.4 
> mod_jk/1.2.25
> mod_rewrite (?)
> Apache Tomcat 5.5.23
> 
> Browser ==> Apache + mod_rewrite ==> mod_jk ==> Tomcat
> 
> 
> This is a Linux machine, and mod_rewrite is used to switch to SSL on certain URLs.
> 
> Problem: the POST data is lost whenever a form on a http page sends data to a page that gets its URL rewritten to https.
> This goes as folllows:
> 
> http page => form post to http url => rewrite url to https, switch to SSL => display https url
> 
> No data arrives when using POST!
> I know there is a bug that limits the maximum post size to x KB, but in my case, the post data is a just a few text fields.
> Any idea as to why this happens?
> 
> Regards,
> 
> 
> Michael

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: POST data lost when switching URL using mod_rewrite and mod_jk

Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
Michael Böckling wrote:
> http page => form post to http url => rewrite url to https, switch to SSL => display https url
>   
What do you mean by 'rewrite url to https, switch to SSL '? Do you send 
HTTP redirect? If so, POST data is obviously lost.

In other case, if you do not send redirect, why do you switch to SSL on 
server side?

-- 
Mikolaj Rydzewski <mi...@ceti.pl>