Sander,
What progress I've made. I've gone from Apache-clueless to
answering my own questions.
Well, not quite answering but at least shedding some light. If I
use url rewriting our Apache 1.3 does not recognize the url because it
thinks the jsessionid is part of the context name, so a 404 results.
Apparently, a rewriting rule can be used to avoid this.
<IfModule mod_rewrite.c>
RewriteEngine on
# Force URLs with a jsessionid to go to Tomcat. Necessary because
# Apache doesn't recognise that the semi-colon is special.
RewriteRule ^(/.*;jsessionid=.*)$ $1 [T=jserv-servlet]
</IfModule>
Your original suggestion for making the proxy and proxied context
the same solved our problem. But perhaps this will be useful for those
who must use url rewriting and Apache 1.3.
Thanks again for your great support,
-=bill
Sander Temme wrote:
On Jan 26, 2007, at 10:48 AM, Wm.A.Stafford wrote:
I forgot to ask about one more aspect of this situation. When we
first realized that session cookies were not coming in to the app we
tried url rewriting and that did not resolve the problem. Does
Apache 1.3 do something to urls that have an explicit session id?
ex. ip_and_context ;jsessionid=blah de blah de blah ¶ms.
This is not ringing a bell for me: mod_proxy should just forward the
request query string unaltered.
While searching for the solution to this I saw a web page that
said a rewrite rule was required if url rewriting is used. Is this
the case and, if so, could you give me an example rule or direct me
to a source for this rule.
Perhaps someone else has any direct experience with this.
S.
Sander Temme wrote:
On Jan 25, 2007, at 1:20 PM, Wm.A.Stafford wrote:
Sander,
Here is a cookie copied from Firefox cookie viewer when
the Apache+Tomcat machine was accessed from another machine.
Name: JSESSIONID
Content: 10FA6EB4F5B24CBA716A7F5DAD1F4B3F
Host: iobis.marine.rutgers.edu
Path: /OBISDEV
^^^^^^^^
Send For: Any type of connecion
Expires: at end of session
The URL to access the Apache+Tomcat application is:
http://iobis.marine.rutgers.edu/OBISBETA/OBIS.jsp
^^^^^^^^^
Just a reminder of the mapping from httpd.conf
ProxyPass /OBISBETA http://localhost:8082/OBISDEV
ProxyPassReverse /OBISBETA localhost:8082/OBISDEV
^^^^^^^^^ ^^^^^^^^
As you can see, the Path: in the cookie does not match the URL path,
so the session cookie will not get sent back to the server.
Since the mod_proxy of Apache 1.3 doesn't support rewriting Cookie
paths, your only option is to change the ProxyPass local path to
match the back-end (and connect to that), or have Tomcat match its
mount path to what the front-end thinks it is.
That's really all I can think of right now.
S.
Thanks,
-=bill
Sander Temme wrote:
On Jan 24, 2007, at 11:00 AM, Wm.A.Stafford wrote:
A bit more info has emerged, the admin believes the Apache
version is 1.3.20.
Running httpd -v will take away any shred of doubt.
I'll see if there is any interest in moving to the latest
Apache but at this point I think that is probably not an option
because there are a lot of other users of this system and they
would all have to buy in. So I will need to proceed with
configuration of the existing version.
Apache has made great strides since 1.3.20. For starters, any 1.3
version after that contains security fixes that you might want.
As no other changes are made to that branch, an upgrade should not
cause you any problems.
The proxy module that came with Apache 1.3 did not have the
ProxyReverseCookiePath directive that I talked about earlier. See
http://httpd.apache.org/docs/1.3/mod/mod_proxy.html
for documentation on the 1.3 mod_proxy module.
Before we make any more guesses about the nature of your problem,
I would like to learn from you whether the Cookie path mismatch is
actually causing your issue. Could you run the following test on
your application:
1) Clear your browser cache and cookie store
2) Connect to your application through the Apache proxy and log in
3) Go back to your cookie store, see if anything emerged and send
us the
contents of any JSESSIONID cookies. Feel free to obfuscate as
you see
fit, as long as we have enough information to work with (domain
and path
are of paramount interest, as well as the complete URL you used to
access your application in step 2.
Thanks,
S.
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
