tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: multiple Set-Cookie headers in initial http response
Date Thu, 13 Nov 2008 10:07:21 GMT
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message