httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarecsni János <jarecsni.ja...@mhc.hu>
Subject RE: FW: cookies gone when proxying
Date Fri, 15 Feb 2002 08:43:07 GMT
Hi,

thanks very much for your reply! Now I at least know why it doesn't work,
and -- according to a Hungarian proverb -- knowing the illness is halfway
towards health.

Now I'll try a few things in my J2EE application:

1. unset the path in the cookie before attaching it to the response
Cookie c = new Cookie();
cookie.setPath("");
(the API doc for Cookie says it'll create version 0 (netscape) cookies
unless version 1 (RFC 2109) is requested explicitly - I don't know yet
what's the difference :)

so generally speaking, I'll try to achieve that the path info does not
matter.

2. if that doesn't work I'll try to use URL rewriting instead of cookies

Well, to answer your question: I think it would be great if cookie-path was
refreshed when proxying, because the whole thing would then be totally
transparent.

I think this whole playing around with mod_rewrite and mod_proxy is vital:
without it I've found no other way to alias a dynamically served request. So
you can alias a file or a directory, you can even ask apache to run a task
when a specific file is requested but you can't do the following:

a) have a resource
http://machine/somepath/someresource?someparameter=somevalue (it's actually
a Java Servlet)
b) create an alias for it so that it can be referred to as:
http://machine/shortname

Because when Apache finishes applying rewriterules (and you don't use either
[R]: it's not good cause it's a redirection, nor [P]: killing cookies :)])
Apache will prepend the document root to the request URI and try to serve it
as that. Which does not make much sense in case of a dynamic resource
(servlets are not "files" to be searched in the doc root). Well, that's why
I resorted to "internally proxying" the request back to the same virtual
host: to achieve a second round of processing. Sorry for the lengthy
explanation, but I wanted be sure that you can understand why it's so vital
to be able to do it. Finally: since it's more and more common among Java
application developers to use apache in front of their tomcat or
JBoss+tomcat platforms, it's of a relatively high importance to be able to
do it seamlessly and transparently.

Are there any arguments in favor of not rewriting the cookie path when
proxying a request?
Are there any chances that - if this is acknowledged to be important - a
patch will soon be released to mod_proxy?

Thanks again
János


|-----Original Message-----
|From: minfrin [mailto:minfrin]On Behalf Of Graham Leggett
|Sent: Friday, February 15, 2002 2:13 AM
|To: dev@httpd.apache.org
|Subject: Re: FW: cookies gone when proxying
|
|
|Jarecsni János wrote:
|
|> Sorry for posting this here, but i got no answer elsewhere.
|> Abstract: when I use pass-through (?) proxying in apache to itself (to
|> achive a 2nd round of processing a request) cookies are lost.
|
|When tomcat sets a cookie, it specifies a path prefix in the cookie to
|limit the scope. This is normal cookie behavior. Change the path using
|mod_rewrite, and your cookies no longer match their original paths, and
|so "disappear".
|
|The question is - ProxyPassReverse munges the Location (for redirects)
|and Content-Location headers to convert from the old to the new URL.
|Should we do the same for "path" in cookies?
|
|Regards,
|Graham
|--
|-----------------------------------------
|minfrin@sharp.fm		"There's a moon
|					over Bourbon Street
|						tonight..."



Mime
View raw message