You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Markus Reis <mr...@gmx.at> on 2008/11/11 12:30:01 UTC
multiple Set-Cookie headers in initial http response
Our Tomcat 5.5 sends 30 cookie (cookie=JSESSIONID=2D79FB71207A83A09B32677B9640693E.jbprod; domain=null; path=/) 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).
The 900 Set-Cookie headers contain each "cookie" JSESSIONID thirty times.
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.
Why does this happen?
kind regards,
Markus
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
---------------------------------------------------------------------
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
Re: multiple Set-Cookie headers in initial http response
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> 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]
Enumeration<String> 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]
Enumeration<String> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Rainer Jung <ra...@kippdata.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: RE: multiple Set-Cookie headers in initial http response
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Markus Reis [mailto:mreis.lists79@gmx.at]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: RE: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: multiple Set-Cookie headers in initial http response
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> 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=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.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by André Warnier <aw...@ice-sa.com>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Pid <p...@pidster.com>.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
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
Re: multiple Set-Cookie headers in initial http response
Posted by André Warnier <aw...@ice-sa.com>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Markus Reis <mr...@gmx.at>.
> > 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple Set-Cookie headers in initial http response
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org