You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Sidney-Woollett <jo...@wardbrook.com> on 2004/11/15 16:20:32 UTC
http->https url rewrite bug TC 5.0.28?
I'm not sure if this is a bug or a misunderstaning on my part - and I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a secure
ssl connection FOR THE SAME DOMAIN and where the session already exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An "action" servlet receives the non-ssl request and redirects to
another secure "action" servlet. The call for the redirect should encode
the URL as follows in the first servlet's service(request, response) method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not appended
to the redirect URL when the protocol switches from http to https:
REQUEST
=======
POST
http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223&action=upd&butaction=checkout&qty_0=1
RESPONSE
========
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
<Host name="www.mytestsite.com" appBase="/ef02/tc/www.mytestsite.com">
<Context path="" docBase="ROOT" debug="0" reloadable="false">
<ResourceLink name="jdbc/D1DB" global="jdbc/D1DB"
type="javax.sql.DataSource"/>
</Context>
</Host>
[snip]
Tomcat possibly nevers "sees" that the request is secure because the SSL
part of the transaction is handled by mod_SSL, and I don't know if this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect -
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ";jsessionid=xxxxxxx" to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: http->https url rewrite bug TC 5.0.28?
Posted by John Sidney-Woollett <jo...@wardbrook.com>.
I should have mentioned that the problem I'm seeing is causing a new
session to be created after the redirect when in fact I want the
original session data prior to the redirect...
John Sidney-Woollett
John Sidney-Woollett wrote:
> I'm not sure if this is a bug or a misunderstaning on my part - and I've
> been searching the archives and googling for most of the day without
> success...
>
> I've got a problem where URL rewriting is failing to correctly encode
> the URL when switching from an insecure (non-ssl) connection to a secure
> ssl connection FOR THE SAME DOMAIN and where the session already exists
> for the insecure connection and COOKIES ARE DISABLED in the browser. I
> can reproduce this behaviour with different browsers.
>
> An "action" servlet receives the non-ssl request and redirects to
> another secure "action" servlet. The call for the redirect should encode
> the URL as follows in the first servlet's service(request, response)
> method:
>
> [snip]
> if (gotoCheckout)
> {
> //goto the checkout
> //this generates the URL
> //https://www.mytestsite.com/CheckoutAction?action=start
> String url = CheckoutAction.getCheckoutActionStartURL(request);
>
> //make sure the JSESSIONID is appended for non-cookie browsers
> url = response.encodeRedirectURL(url);
>
> response.sendRedirect(url);
> return;
> }
> [snip]
>
> Looking at the headers, you can see that the JSESSIONID is not appended
> to the redirect URL when the protocol switches from http to https:
>
> REQUEST
> =======
> POST
> http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
> HTTP/1.1
> Host: www.mytestsite.com
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
> Gecko/20030728 Mozilla Firebird/0.6.1
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
>
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Proxy-Connection: keep-alive
> Referer:
> http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
>
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 66
> ret=%2Fimage%2F6503740500223&action=upd&butaction=checkout&qty_0=1
>
> RESPONSE
> ========
> HTTP/1.x 302 Moved Temporarily
> Date: Mon, 15 Nov 2004 13:38:23 GMT
> Server: Apache/1.3.29
> Location: https://www.mytestsite.com/CheckoutAction?action=start
> Content-Length: 0
> Content-Type: text/plain
> Connection: close
>
>
> Setup
>
> Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
>
> Apache is configured with two virtual directives; one for port 80 and
> one for post 443 and the requests are forwarded by mod_jk to tomcat
> which has the following in its server.xml config:
>
> [snip]
> <Host name="www.mytestsite.com" appBase="/ef02/tc/www.mytestsite.com">
> <Context path="" docBase="ROOT" debug="0" reloadable="false">
> <ResourceLink name="jdbc/D1DB" global="jdbc/D1DB"
> type="javax.sql.DataSource"/>
> </Context>
> </Host>
> [snip]
>
> Tomcat possibly nevers "sees" that the request is secure because the SSL
> part of the transaction is handled by mod_SSL, and I don't know if this
> has a bearing on the issue?
>
> My question, should the JSESSIONID be appended in the encoded redirect -
> I think so?
>
> And if it should, am I doing something wrong. Or is there a bug?
>
> If there is a bug, should I manually append the ";jsessionid=xxxxxxx" to
> the URL to workaround the problem.
>
> Can anyone shed any light on this?
>
> Many thanks
>
> John Sidney-Woollett
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org