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:[EMAIL PROTECTED] > 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:[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] > >> > >> > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
