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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
