Markus Reis wrote:
[...]
> There are however three new observation results:
> (1) This also happens with GET requests (Previously I tested GET
requests only with an empty query string - sorry for that)
Well, if you keep on changing the conditions, we'll never get out of
this ;-)
> I have now installed an equivalent Tomcat (actually it is a JBoss
that uses Tomcat 5.5 as it's ServletEngine) instance on my own PC - so
there's nothing between the client (a web browser on my PC) and the
server (a Tomcat instance running on my PC). The observed results are
the same.
Ultimately, there must be something very wrong in the configuration or
one of the modules that you are using, because I cannot quite imagine
why Tomcat would generate umpteen session-id's and corresponding cookies
for a single request. But I am not at all familiar with JBoss, and have
no idea what kind of "layer" there may still be between your browser and
Tomcat.
Since you mention JBoss (which I don't know), is that still some kind of
HTTP server front-end to Tomcat ?
I see that you are using port 48080 to access it.
In your Tomcat "server.xml", is there a Connector with that same port
number ?
It seems that this is a problem only you are having, some there must be
something quite unique somewhere.
To narrow it down, you really need to be systematic, see below about
GET/POST.
To my knowledge, Tomcat will only generate a new session and new
session-id if :
- it receives a request without a JSESSIONID cookie
- and there is also no session-id encoded in the request URL
and it will only generate one session, and one JSESSIONID cookie per
request.
That you do not see this strange behaviour from the second request on,
is normal, because your browser is then sending a JSESSIONID Cookie
header back to Tomcat, so it finds it and does not need to generate a
new session.
But, your arithmetic observations would tend to indicate that there is
one session-id generated per first request, plus one per GET/POST
parameter, which really does not make sense at all..., specially since
all these corresponding Set-Cookie headers end up being sent back in a
single response.
It is a bit far-fetched to make guesses at this point, but it almost
looks as if there is still something between your browser and Tomcat,
that intercepts the request, splits it into n requests for Tomcat, gets
n responses from Tomcat, and puts them back together into one single
response. I cannot quite imagine what that could be.
Does your Tomcat AccessDumperValve show one single request, or n ?
After this, and if you can really pin down what happens using a precise
set of conditions with GET/POST below, I am afraid I am out of my depth,
and cannot help you further.
And, how do you do this exactly, to switch between a GET request and a
POST request ?
In the case of a GET request I add the parameters I want to send in the query string
(http://localhost:48080/webAntWeb/NewSession?BEA_KURZ=sj&BEARBEITER=Josef+Schweiger&BERATERNR=&BANK=47150&FILIALE=VB+N%D6-Mitte&VORVERTRAG=&VER_BEGINN=&VER_ABLAUF=&KUNDENNR=77777&AKAD=&VORNAME=Hilde&ZUNAME=Musterfrau&GESCHL=W&GEBDAT=05.05.1965&SVNR=4085050565&STRASSE=Stra%DFe+21&PLZ=1090&ORT=Wien&TELNR=01+%2F+31380+%2F+999&EMAIL=&AUSART=02&AUSNR=666666&AUSBEHOERDE=Pol.Dion.+Wien&KTONR=999999999&BLZ=43000&NAME_VV=&NAME2_VV=&STRASSE_VV=&PLZ_VV=&ORT_VV=&SEL_VTR=&testfall=1&aktion=)
In the case of a POST request I use a html form with the above input fields and
submit the form.
I am not sure that the following is the reason of your problems, but
since you are testing and trying to narrow-down the problem conditions,
it helps to be precise.
The difference between a POST and a GET is not whether the parameters
are transmitted or not in the URL's query string. POST and GET are two
different HTTP "verbs" sent to the server, and the way in which the
parameters are sent depends of the "enctype" attribute of your <form> tag.
(I use the word "parameter" a bit loosely below, but explaining that
would make it even longer, so I'll skip it)
a) <form action="..." method="GET"
enctype="application/x-www-form-urlencoded">
will make a "GET" request, with the parameters in the query string (the
part after the ? ) of the target URL
(In other words, you can simulate your "URL" example above this way,
even using a form)
b) <form action="..." method="GET" enctype=""multipart/form-data"">
will make a "GET" request, with the parameters sent in the body of the
request, not as a query string
(In other words, the same form, just by changing the "enctype", will now
send the same parameters in the request body, not in the URL, but the
call will still be a GET)
c) <form action="..." method="POST"
enctype="application/x-www-form-urlencoded">
will make a POST request, with the parameters sent in the URL's query
string, despite the fact that this is a "POST"
d) <form action="..." method="POST" enctype="multipart/form-data">
will make a POST request, with the parameters sent in the body
If you do not specify the above "method" and "enctype" attributes, then
you fall into various kinds of browser default behaviours, which may hit
you where you do not expect, and confuse things.
By default, if you just type a URL in the browser, with a query string,
your browser will make a GET request like case (a).
By default also, if you have a <form> containing input fields, your
browser *may* automatically use method (d) above, but that is a bit less
certain.
In other words, force it, by specifying "method" and "enctype"
explicitly, and you will not have problems or confusion.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
