Re: multiple Set-Cookie headers in initial http response
Or use the same trick
new Throwable(Oups).printStackTrace();
inside your listener to not just write out session creations and
destroys, but the code stack at that moment. Above Wrapper is nicer,
using the same trick in your existing listener is simpler and faster.
I did that and finally found the problematic code (of course in the web
application - in doGet/doPost of NewSessionServlet - and not in Tomcat/JBoss):
[code]
EnumerationString params = request.getParameterNames();
DynamicDataTransferObject ddto = (DynamicDataTransferObject)
request.getSession().getAttribute(NEW_SESSION_LAST_DTO);
if (ddto == null)
ddto = new DynamicDataTransferObject();
while (params.hasMoreElements()) {
String key = params.nextElement();
if (!request.getParameter(key).equals(ddto.get(key)))
request.getSession().invalidate();
ddto.set(key, request.getParameter(key));
}
request.getSession().setAttribute(NEW_SESSION_LAST_DTO, ddto);
[/code]
This code checks whether a complex object representing all input/request params
has been resubmitted with exactly the same values and invalidated the session x
times (where x is the number of different parameter values). This is also done
when a completely new session exists (and the params are sent for the first
time). This is complete non-sense of course.
My only apology to you is that I have not written this code and that I did not
know of it's existence :-). Still I'd like to say thank you for your great help
and valuable comments.
I now changed the code to:
[code]
EnumerationString params = request.getParameterNames();
DynamicDataTransferObject ddto = (DynamicDataTransferObject)
request.getSession().getAttribute(NEW_SESSION_LAST_DTO);
if (ddto == null)
ddto = new DynamicDataTransferObject();
else {
boolean invalidateSession = false;
while (params.hasMoreElements()) {
String key = params.nextElement();
if (!request.getParameter(key).equals(ddto.get(key)))
invalidateSession = true;
ddto.set(key, request.getParameter(key));
}
if (invalidateSession)
request.getSession().invalidate();
}
request.getSession().setAttribute(NEW_SESSION_LAST_DTO, ddto);
[/code]
Now session.invalidate() is called only once and only in the case where the
client already called NewSessionServlet before in the existing browser session
with different request parameter values.
One last question: I'm not sure whether it is good to call session.invalidate()
in a doPost/doGet method of a HttpServlet? Could this have negative/problematic
side-effects or is this OK?
many thanks kind regards,
Markus
--
Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus,
Markus Reis wrote:
I [set up a filter that emits stack traces] and finally found the
problematic code (of course in the web application - in doGet/doPost
of NewSessionServlet - and not in Tomcat/JBoss):
[snip]
while (params.hasMoreElements()) {
String key = params.nextElement();
if (!request.getParameter(key).equals(ddto.get(key)))
request.getSession().invalidate();
ddto.set(key, request.getParameter(key));
}
request.getSession().setAttribute(NEW_SESSION_LAST_DTO, ddto);
[snip]
This is complete non-sense of course.
:)
My only apology to you is that I have not written this code and that
I did not know of it's existence :-). Still I'd like to say thank you for
your great help and valuable comments.
No problem. Just make sure you remember how you tracked-down this
problem so you can add this technique to your mental toolbox.
One last question: I'm not sure whether it is good to call
session.invalidate() in a doPost/doGet method of a HttpServlet? Could
this have negative/problematic side-effects or is this OK?
I'm not sure where else you would call session.invalidate(). Sure, you
could put it into a separate method, but your servlet pretty much always
has to have doPost or doGet called by the container. There's no reason
to fear invalidating a session.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkdnPgACgkQ9CaO5/Lv0PB5FACfYbHM0ntpTOR2tmZpMxhUaOq2
Va4AoKg5iecm8u6Ll1b3XduUZ6StKqpT
=cJfW
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Markus Reis wrote: [...] Further I found out that this happens only with an initial POST request - if I do the same via GET only one Set-Cookie header is returned (I wrote before that I was not able to reproduce those 900 Set-Cookie headers on my PC, but that was due to the fact that I sent the request as a GET - If I send the same data via a POST request I also get ~900 Set-Cookie headers, with the only difference that all of them always contain the exactly same JSESSIONID). I only get those 900 Set-Cookie headers after/at the initial request; Subsequent requests only have one cookie in http request and response header and look pretty normal. Well, that is a lot of progress. You have already eliminated all the client stations, the client network and the client proxy server. That's at least 50% of the elephant. Is there still something between your PC and the Tomcat server, or is your PC talking directly to the Tomcat server (no front-end server, no proxy, nothing like that ) ? 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. 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=sjBEARBEITER=Josef+SchweigerBERATERNR=BANK=47150FILIALE=VB+N%D6-MitteVORVERTRAG=VER_BEGINN=VER_ABLAUF=KUNDENNR=7AKAD=VORNAME=HildeZUNAME=MusterfrauGESCHL=WGEBDAT=05.05.1965SVNR=4085050565STRASSE=Stra%DFe+21PLZ=1090ORT=WienTELNR=01+%2F+31380+%2F+999EMAIL=AUSART=02AUSNR=66AUSBEHOERDE=Pol.Dion.+WienKTONR=9BLZ=43000NAME_VV=NAME2_VV=STRASSE_VV=PLZ_VV=ORT_VV=SEL_VTR=testfall=1aktion=) In the case of a POST request I use a html form with the above input fields and submit the form. 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) (2) The number of cookie headers is equal to the number of parameters sent (either via POST or GET) + 1 (i.e. 5 parameters sent results in 6 cookie headers) (3) The number of Set-Cookie headers is number of cookie headers multiplied with number of cookie headers (i.e. if number of cookie headers is 6 the number of Set-Cookie headers is 36) And, can you try this in Firefox e.g., with the LiveHttpHeaders add-on, to see exactly at the PC level which headers are being sent, and which are being received, in each case ? LiveHttpHeaders shows me x Set-Cookie headers in the response where x is equal to number of cookie headers in the output of RequestDumperValve (and which is basically the number of distinct JSESSIONID cookies). LiveHttpHeaders displays the same response header for POST and GET requests. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Since you mention JBoss (which I don't know), is that still some kind of HTTP server front-end to Tomcat ? No (at least not AFAIK). 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 ? Yes. 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. I also start to believe in that. I added a HttpSessionListener to my web.xml, which only makes a System.out.println(session created | destroyed) whenever one of those events occurs and found out that before NewSession Servlet (remember the url I call is http://localhost:48080/webAntWeb/NewSession?...) is entered I see the following sequence Session created Session destroyed as often as number of cookie headers-1 and at the end there's one Session created which is then used in the following conversation's requests. But what could be between that? What else could I do? I also printed out how often the servlet context initialized event occurrs (via a ServletContextListener impl), and this happens exactly once - as expected. Does your Tomcat AccessDumperValve show one single request, or n ? One single request only. GET requests are always application/x-www-form-urlencoded (even if I set enctype=multipart/form-data Firefox LiveHttpHeaders doesn't show in the request). POST requests were enctype=application/x-www-form-urlencoded (if i change to enctype=multipart/form-data I get an exception back from the webapp). -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiple Set-Cookie headers in initial http response
From: André Warnier [mailto:[EMAIL PROTECTED] Subject: Re: multiple Set-Cookie headers in initial http response Since you mention JBoss (which I don't know), is that still some kind of HTTP server front-end to Tomcat ? JBoss is a full Java EE app server, using Tomcat internally to supply the servlet container subset of the Java EE spec. It's comparable to WebSphere and WebLogic, but open source. Some of the Tomcat committers work on JBoss as well. 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... Sounds like something in the webapp is invalidating the current session and creating a new one each time it processes a parameter. Perhaps code that should be executed once is incorrectly placed inside a loop? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
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=sjBEARBEITER=Josef+SchweigerBERATERNR=BANK=47150FILIALE=VB+N%D6-MitteVORVERTRAG=VER_BEGINN=VER_ABLAUF=KUNDENNR=7AKAD=VORNAME=HildeZUNAME=MusterfrauGESCHL=WGEBDAT=05.05.1965SVNR=4085050565STRASSE=Stra%DFe+21PLZ=1090ORT=WienTELNR=01+%2F+31380+%2F+999EMAIL=AUSART=02AUSNR=66AUSBEHOERDE=Pol.Dion.+WienKTONR=9BLZ=43000NAME_VV=NAME2_VV=STRASSE_VV=PLZ_VV=ORT_VV=SEL_VTR=testfall=1aktion=) 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
Re: RE: multiple Set-Cookie headers in initial http response
Sounds like something in the webapp is invalidating the current session and creating a new one each time it processes a parameter. Perhaps code that should be executed once is incorrectly placed inside a loop? I have the impression that this happens already before the webapp comes into play, because the HttpSessionListener implementation prints out those Session created | destroyed events before the NewSession servlet is even entered. It seems to be some component in Tomcat (or JBoss) that acts in front of the Servlet and creates those sessions (per request parameter). But maybe I'm also completely mistaken ... markus -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: multiple Set-Cookie headers in initial http response
From: Markus Reis [mailto:[EMAIL PROTECTED] Subject: Re: RE: multiple Set-Cookie headers in initial http response I have the impression that this happens already before the webapp comes into play, because the HttpSessionListener implementation prints out those Session created | destroyed events before the NewSession servlet is even entered. The webapp (including filters and JSPs, not just servlets) can create and invalidate sessions at its whim; each such event will trigger a call to the HttpSessionListener. It seems to be some component in Tomcat (or JBoss) that acts in front of the Servlet and creates those sessions (per request parameter). Then why is it happening only with *your* webapp and not to the millions of other webapps deployed on Tomcat and JBoss? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus,
Markus Reis wrote:
I added a HttpSessionListener to my web.xml, which only makes a
System.out.println(session created | destroyed) whenever one of those
events occurs and found out that before NewSession Servlet (remember the url
I call is http://localhost:48080/webAntWeb/NewSession?...) is entered I see
the following sequence
Session created
Session destroyed
as often as number of cookie headers-1 and at the end there's one
Session created
which is then used in the following conversation's requests.
Really? So, given a fresh TC startup and a browser with no cookies, a
single request results in /many/ Session created/session destroyed
messages on your console?
That's bad.
That suggests to me that you have some code that is repeatedly
invalidating the session and then creating another one. If that's the
case, it's no wonder you are getting so many Set-Cookie headers.
Try this:
Write a filter that wraps the HttpServletResponde object with an
HttpServletResponseWrapper object that you customize. Override the
addCookie method like this:
public void addCookie(Cookie c)
{
super.addCookie(c);
new Throwable(Created Cookie).printStackTrace();
}
This will emit a stack trace whenever code adds a cookie to the
response. Try this with a small number of request parameters ;)
Look to see where all the addCookie headers are coming from. They'll
probably be coming from Tomcat's internal code, but you should look
further up the stack to see if it's in your code. Maybe a filter. Maybe
a servlet. Check those places in the code. They may be killing the
current session and re-creating it inappropriately.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkcXtIACgkQ9CaO5/Lv0PDItgCdG79ifx/CUjwsjSKkPFhGWfpP
yQ8Anjho2cO17oV28v79q8PDfTomrkfu
=/6D+
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Christopher Schultz schrieb:
Try this:
Write a filter that wraps the HttpServletResponde object with an
HttpServletResponseWrapper object that you customize. Override the
addCookie method like this:
public void addCookie(Cookie c)
{
super.addCookie(c);
new Throwable(Created Cookie).printStackTrace();
}
This will emit a stack trace whenever code adds a cookie to the
response. Try this with a small number of request parameters ;)
Or use the same trick
new Throwable(Oups).printStackTrace();
inside your listener to not just write out session creations and
destroys, but the code stack at that moment. Above Wrapper is nicer,
using the same trick in your existing listener is simpler and faster.
Regards,
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) Are they all identical? No. They are ALL different (and they also differ from response to response) and 900 Set-Cookie (header=Set-Cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; Path=/; Secure) headers in the http response header back to the external clients (during the initial http request/response). Same here: identical? No. Each of the 30 DIFFERENT session id's from above are repeated thirty times. The 900 Set-Cookie headers contain each cookie JSESSIONID thirty times. That is crazy! How are you observing this behavior? LiveHTTPHeaders/http protocol sniffer? Wireshark/packet sniffer? Yes it is crazy - I observed this using org.apache.catalina.valves.RequestDumperValve in my server.xml If I submit the same request from my machine I get a only/as expected one cookie and one Set-Cookie header back in the initial response. Er... what do you mean from my machine? What are you using when you get 900 Set-Cookie headers? My machine is my PC at work. The requests where a repsonse with 900 SetCookie headers is returned, are sent from PC's of our partners, which operate in one single network (and thus all have the same IP, which is the IP of the partner network's proxy server). If I use some other PC connected to the internet I have the same expected behaviour as from my PC at work. So those responses are only/exclusively produced for requests coming from PC's of our partners. markus -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/index.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Markus Reis wrote: Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) Are they all identical? No. They are ALL different (and they also differ from response to response) and 900 Set-Cookie (header=Set-Cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; Path=/; Secure) headers in the http response header back to the external clients (during the initial http request/response). Same here: identical? No. Each of the 30 DIFFERENT session id's from above are repeated thirty times. The 900 Set-Cookie headers contain each cookie JSESSIONID thirty times. That is crazy! How are you observing this behavior? LiveHTTPHeaders/http protocol sniffer? Wireshark/packet sniffer? Yes it is crazy - I observed this using org.apache.catalina.valves.RequestDumperValve in my server.xml If I submit the same request from my machine I get a only/as expected one cookie and one Set-Cookie header back in the initial response. Er... what do you mean from my machine? What are you using when you get 900 Set-Cookie headers? My machine is my PC at work. The requests where a repsonse with 900 SetCookie headers is returned, are sent from PC's of our partners, which operate in one single network (and thus all have the same IP, which is the IP of the partner network's proxy server). If I use some other PC connected to the internet I have the same expected behaviour as from my PC at work. So those responses are only/exclusively produced for requests coming from PC's of our partners. markus Old African proverb : he who wants to eat an elephant, should do it a little bit at a time. I am not basing the following on any deep knowledge of Tomcat, just trying to use the logical cues from what you said so far and the way HTTP servers and browsers normally react. 1) How do you *precisely* know that Tomcat is actually sending 900 Set-Cookie Headers ? does the RequestDumperValve also dump the response ? or is that what you see in the client browser ? In other words, are you really sure that it is Tomcat who is sending all these Set-Cookie headers, or could it be the customer's proxy adding/multiplying them ? (Not that I would know how it could do that, but that's another matter) 2) The client browser gets 900 Set-Cookie headers, of which the basic set of different ones is 30, each multiplied 30 times. So the client browser ends up with 30 cookies set ? Or just one, in the end ? 3) Does this number 30 relate in some way to how many separate stations at your customer access your Tomcat server ? For example, assuming that there would be a way to reset everything, and then turn on a single customer station, and access your Tomcat server once, how many Set-cookies would that one browser get in return ? And then, what if a second station now sends a request ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Markus Reis wrote: [...] Further I found out that this happens only with an initial POST request - if I do the same via GET only one Set-Cookie header is returned (I wrote before that I was not able to reproduce those 900 Set-Cookie headers on my PC, but that was due to the fact that I sent the request as a GET - If I send the same data via a POST request I also get ~900 Set-Cookie headers, with the only difference that all of them always contain the exactly same JSESSIONID). I only get those 900 Set-Cookie headers after/at the initial request; Subsequent requests only have one cookie in http request and response header and look pretty normal. Well, that is a lot of progress. You have already eliminated all the client stations, the client network and the client proxy server. That's at least 50% of the elephant. Is there still something between your PC and the Tomcat server, or is your PC talking directly to the Tomcat server (no front-end server, no proxy, nothing like that ) ? And, how do you do this exactly, to switch between a GET request and a POST request ? And, can you try this in Firefox e.g., with the LiveHttpHeaders add-on, to see exactly at the PC level which headers are being sent, and which are being received, in each case ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
André Warnier wrote: Markus Reis wrote: Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) Are they all identical? No. They are ALL different (and they also differ from response to response) and 900 Set-Cookie (header=Set-Cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; Path=/; Secure) headers in the http response header back to the external clients (during the initial http request/response). Same here: identical? No. Each of the 30 DIFFERENT session id's from above are repeated thirty times. The 900 Set-Cookie headers contain each cookie JSESSIONID thirty times. That is crazy! How are you observing this behavior? LiveHTTPHeaders/http protocol sniffer? Wireshark/packet sniffer? Yes it is crazy - I observed this using org.apache.catalina.valves.RequestDumperValve in my server.xml If I submit the same request from my machine I get a only/as expected one cookie and one Set-Cookie header back in the initial response. Er... what do you mean from my machine? What are you using when you get 900 Set-Cookie headers? My machine is my PC at work. The requests where a repsonse with 900 SetCookie headers is returned, are sent from PC's of our partners, which operate in one single network (and thus all have the same IP, which is the IP of the partner network's proxy server). If I use some other PC connected to the internet I have the same expected behaviour as from my PC at work. So those responses are only/exclusively produced for requests coming from PC's of our partners. markus Old African proverb : he who wants to eat an elephant, should do it a little bit at a time. I am not basing the following on any deep knowledge of Tomcat, just trying to use the logical cues from what you said so far and the way HTTP servers and browsers normally react. 1) How do you *precisely* know that Tomcat is actually sending 900 Set-Cookie Headers ? does the RequestDumperValve also dump the response ? or is that what you see in the client browser ? In other words, are you really sure that it is Tomcat who is sending all these Set-Cookie headers, or could it be the customer's proxy adding/multiplying them ? (Not that I would know how it could do that, but that's another matter) 2) The client browser gets 900 Set-Cookie headers, of which the basic set of different ones is 30, each multiplied 30 times. So the client browser ends up with 30 cookies set ? Or just one, in the end ? 3) Does this number 30 relate in some way to how many separate stations at your customer access your Tomcat server ? For example, assuming that there would be a way to reset everything, and then turn on a single customer station, and access your Tomcat server once, how many Set-cookies would that one browser get in return ? And then, what if a second station now sends a request ? As a test, why don't you set a cookie on each client PC, (containing a unique identifier, perhaps a username or something else that will identify individual PCs or users), to see if that gets multiplied back to you too. If it does, you may discern more about the pattern of failure. I only get those 900 Set-Cookie headers after/at the initial request; Subsequent requests only have one cookie in http request and response header and look pretty normal. -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/index.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
André Warnier wrote: Markus Reis wrote: Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) Are they all identical? No. They are ALL different (and they also differ from response to response) and 900 Set-Cookie (header=Set-Cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; Path=/; Secure) headers in the http response header back to the external clients (during the initial http request/response). Same here: identical? No. Each of the 30 DIFFERENT session id's from above are repeated thirty times. The 900 Set-Cookie headers contain each cookie JSESSIONID thirty times. That is crazy! How are you observing this behavior? LiveHTTPHeaders/http protocol sniffer? Wireshark/packet sniffer? Yes it is crazy - I observed this using org.apache.catalina.valves.RequestDumperValve in my server.xml If I submit the same request from my machine I get a only/as expected one cookie and one Set-Cookie header back in the initial response. Er... what do you mean from my machine? What are you using when you get 900 Set-Cookie headers? My machine is my PC at work. The requests where a repsonse with 900 SetCookie headers is returned, are sent from PC's of our partners, which operate in one single network (and thus all have the same IP, which is the IP of the partner network's proxy server). If I use some other PC connected to the internet I have the same expected behaviour as from my PC at work. So those responses are only/exclusively produced for requests coming from PC's of our partners. markus Old African proverb : he who wants to eat an elephant, should do it a little bit at a time. I am not basing the following on any deep knowledge of Tomcat, just trying to use the logical cues from what you said so far and the way HTTP servers and browsers normally react. 1) How do you *precisely* know that Tomcat is actually sending 900 Set-Cookie Headers ? does the RequestDumperValve also dump the response ? or is that what you see in the client browser ? In other words, are you really sure that it is Tomcat who is sending all these Set-Cookie headers, or could it be the customer's proxy adding/multiplying them ? (Not that I would know how it could do that, but that's another matter) 2) The client browser gets 900 Set-Cookie headers, of which the basic set of different ones is 30, each multiplied 30 times. So the client browser ends up with 30 cookies set ? Or just one, in the end ? 3) Does this number 30 relate in some way to how many separate stations at your customer access your Tomcat server ? For example, assuming that there would be a way to reset everything, and then turn on a single customer station, and access your Tomcat server once, how many Set-cookies would that one browser get in return ? And then, what if a second station now sends a request ? As a test, why don't you set a cookie on each client PC, (containing a unique identifier, perhaps a username or something else that will identify individual PCs or users), to see if that gets multiplied back to you too. If it does, you may discern more about the pattern of failure. p - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
Markus Reis wrote: Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) Are they all identical? No. They are ALL different (and they also differ from response to response) and 900 Set-Cookie (header=Set-Cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; Path=/; Secure) headers in the http response header back to the external clients (during the initial http request/response). Same here: identical? No. Each of the 30 DIFFERENT session id's from above are repeated thirty times. The 900 Set-Cookie headers contain each cookie JSESSIONID thirty times. That is crazy! How are you observing this behavior? LiveHTTPHeaders/http protocol sniffer? Wireshark/packet sniffer? Yes it is crazy - I observed this using org.apache.catalina.valves.RequestDumperValve in my server.xml If I submit the same request from my machine I get a only/as expected one cookie and one Set-Cookie header back in the initial response. Er... what do you mean from my machine? What are you using when you get 900 Set-Cookie headers? My machine is my PC at work. The requests where a repsonse with 900 SetCookie headers is returned, are sent from PC's of our partners, which operate in one single network (and thus all have the same IP, which is the IP of the partner network's proxy server). If I use some other PC connected to the internet I have the same expected behaviour as from my PC at work. So those responses are only/exclusively produced for requests coming from PC's of our partners. markus Old African proverb : he who wants to eat an elephant, should do it a little bit at a time. I am not basing the following on any deep knowledge of Tomcat, just trying to use the logical cues from what you said so far and the way HTTP servers and browsers normally react. 1) How do you *precisely* know that Tomcat is actually sending 900 Set-Cookie Headers ? does the RequestDumperValve also dump the response ? or is that what you see in the client browser ? In other words, are you really sure that it is Tomcat who is sending all these Set-Cookie headers, or could it be the customer's proxy adding/multiplying them ? (Not that I would know how it could do that, but that's another matter) Yes, the RequestDumperValve also dumps the response - therefore I'm SURE that it is Tomcat that sends the 900 Set-Cookie headers and no other network component between client and server. 2) The client browser gets 900 Set-Cookie headers, of which the basic set of different ones is 30, each multiplied 30 times. So the client browser ends up with 30 cookies set ? Or just one, in the end ? The client sends only one cookie in the following requests (this cookie is the last one in the list of Set-Cookie headers). All those requests only have this one/single cookie in their requests (and responses). 3) Does this number 30 relate in some way to how many separate stations at your customer access your Tomcat server ? For example, assuming that there would be a way to reset everything, and then turn on a single customer station, and access your Tomcat server once, how many Set-cookies would that one browser get in return ? And then, what if a second station now sends a request ? I have no idea how many separate clients/workstations are accessing our Tomcat (due to the partner network's proxy) - it could be thirty, but still: How should Tomcat know about that? I also have no possibility to go (physically) to our partner and try something out. Further I found out that this happens only with an initial POST request - if I do the same via GET only one Set-Cookie header is returned (I wrote before that I was not able to reproduce those 900 Set-Cookie headers on my PC, but that was due to the fact that I sent the request as a GET - If I send the same data via a POST request I also get ~900 Set-Cookie headers, with the only difference that all of them always contain the exactly same JSESSIONID). -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus, Markus Reis wrote: Yes, the RequestDumperValve also dumps the response - therefore I'm SURE that it is Tomcat that sends the 900 Set-Cookie headers and no other network component between client and server. I second Andre's recommendation that you use LiveHTTPHeaders to capture the actual response received at the client. It's possible that there is a bug in the RequestDumperValve that emits too many Set-Cookie headers (but that seems unlikely since they are all different). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbLE4ACgkQ9CaO5/Lv0PDr2wCfW2o/qbTR8R7MDJDUGK0ka8ED OuYAmwWMkf1zMVSSyeRbCO9D8fYc05N/ =gt7m -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Set-Cookie headers in initial http response
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus, Markus Reis wrote: Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) Are they all identical? and 900 Set-Cookie (header=Set-Cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; Path=/; Secure) headers in the http response header back to the external clients (during the initial http request/response). Same here: identical? The 900 Set-Cookie headers contain each cookie JSESSIONID thirty times. That is crazy! How are you observing this behavior? LiveHTTPHeaders/http protocol sniffer? Wireshark/packet sniffer? If I submit the same request from my machine I get a only/as expected one cookie and one Set-Cookie header back in the initial response. Er... what do you mean from my machine? What are you using when you get 900 Set-Cookie headers? (Wow... 900?! Awesome.) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkZ/IsACgkQ9CaO5/Lv0PCYrwCfW6biV1GJwkW621Ye8o0N3dcc JHIAn2RNynlAxaya/QoF/P6fDDFBk+9M =4snt -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
