x-Age=" non-zero-digit *DIGIT
where:
non-zero-digit= %x31-39
; digits 1 through 9
However, to my understanding, Section 4.1.1 refers to how user agents should
store cookie data
No. Section 4.1.1 defines the rules servers should follow when
generating set-cook
ge=0 seems to be common practice, e.g., :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#max-agenumber
I therefore wonder what the rationale for omitting Max-Age=0 is, and whether
this is considered a bug.
Regards,
Marcel Steinbeck
try your hand at a patch?
>
> Mark
>
>
> >
> >
> >Jim
> >
> >On Thu, Mar 16, 2017 at 6:15 AM, Mark Thomas wrote:
> >
> >> On 15/03/17 21:56, Jim Griswold wrote:
> >> > Hi everyone,
> >> >
> >> > After a rec
wrote:
>
>> On 15/03/17 21:56, Jim Griswold wrote:
>> > Hi everyone,
>> >
>> > After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a
>> syntax
>> > change in the Set-Cookie header generated by Tomcat, and I was
>h
> syntax
> > change in the Set-Cookie header generated by Tomcat, and I was hoping to
> > confirm whether this is intentional or if I'm doing something
> incorrectly.
> >
> > The background:
> >
> > After upgrading Tomcat, some automated tests starte
On 15/03/17 21:56, Jim Griswold wrote:
> Hi everyone,
>
> After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a syntax
> change in the Set-Cookie header generated by Tomcat, and I was hoping to
> confirm whether this is intentional or if I'm doing someth
Hi everyone,
After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a syntax
change in the Set-Cookie header generated by Tomcat, and I was hoping to
confirm whether this is intentional or if I'm doing something incorrectly.
The background:
After upgrading Tomcat, some
; 1.) web.xml
>
>
>
>
> false
>
>
>
>
>
>
>
> 2.) context.xml
>
>
> useHttpOnly="false"
>
Did you specify this as an attribute?
...
Regards,
Violeta
> curl -I http://localhost:8801
> HTTP/1
ttp://localhost:8801
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=7A54CAEC2733B3AB015ED09F9A68C72A; Path=/; *HttpOnly*
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 305
Date: Wed, 09 Mar 2016 15:41:48 GMT
*Server version: Apache Tomcat/8.0.30Server built: Dec
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: set-cookie
>
> > Thread.currentThread().dumpStack();
>
> Or the more traditional:
>
> new Throwable("Stack Dump").printStackTrace();
And if we look inside java.lang.Thr
On Wed, May 26, 2010 at 2:04 PM, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chuck,
>
> On 5/24/2010 3:55 PM, Caldarale, Charles R wrote:
>>> From: banto [mailto:banto...@gmail.com]
>>> Subject: Re: set-coo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 5/24/2010 3:55 PM, Caldarale, Charles R wrote:
>> From: banto [mailto:banto...@gmail.com]
>> Subject: Re: set-cookie
>>
>> i´m using something like
>> System.out.println(Thread.currentThread().getStackTra
great guys for a great forum!!!
n828cl wrote:
>
>> From: banto [mailto:banto...@gmail.com]
>> Subject: Re: set-cookie
>>
>> i´m using something like
>> System.out.println(Thread.currentThread().getStackTrace());
>
> What you got was a display of
> From: banto [mailto:banto...@gmail.com]
> Subject: Re: set-cookie
>
> i´m using something like
> System.out.println(Thread.currentThread().getStackTrace());
What you got was a display of the array object - not very interesting. Either
iterate through the array, displaying each
.forward(request, response);
>>
>> the response contains also the set cookie header...it is automatically
>> done
>> by tomcat...
>
> You can "safely" call RequestDispatcher.forward() without sending a
> Set-Cookie header. The code to your doPost method
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Banto,
On 5/22/2010 12:01 PM, banto wrote:
>
> Hi Chuck,
>
> i have found out who is generating that in my code:
>
> dispatcher.forward(request, response);
>
> the response contains also the set cookie header...it is
Hi Chuck,
i have found out who is generating that in my code:
dispatcher.forward(request, response);
the response contains also the set cookie header...it is automatically done
by tomcat...
n828cl wrote:
>
>> From: banto [mailto:banto...@gmail.com]
>> Subject: RE: set-cooki
> From: banto [mailto:banto...@gmail.com]
> Subject: RE: set-cookie
>
> ..then where the
>
> set-cookie come from if not from the line
> getServletContext().setAttribute("products", products);?
That's part of the init() method, called when the servlet init
//if we reached here, no exception, cookie is valid the header name is
Set-Cookie for both "old" and v.1 ( RFC2109 )
//RFC2965 is not supported by browsers and the Servlet spec asks for 2109.
//in any case the cookie is added to the response header with Set-Cookie
keyword as
..then where the
set-cookie come from if not from the line
getServletContext().setAttribute("products", products);?
actually i added this line to another servlet but no
set-cookie header is sent?
thanks
n828cl wrote:
>
>> From: André Warnier [mailto:a...@ice-sa.com]
> From: banto [mailto:banto...@gmail.com]
> Subject: set-cookie
>
> Now the code is something like:
>
> public class FrontController extends HttpServlet {
>
> public void init() throws ServletException {
>
> HashMap products = new HashMap();
&
> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: set-cookie
>
> // Store products in the ServletContext
> getServletContext().setAttribute("products", products);
>
> Presumably, if you store something in the context, it is because you
>
banto wrote:
Hi gurus,
my problem here is that i'm trying to understnad a servlet code that makes
tomcat to send the
Set-Cookie: JSESSIONID=8BCB60D6F6B9394B4ABD2FDD007BDB39; Path=/store
header.
Now the code is something like:
public class FrontController extends HttpServlet {
p
Hi gurus,
my problem here is that i'm trying to understnad a servlet code that makes
tomcat to send the
Set-Cookie: JSESSIONID=8BCB60D6F6B9394B4ABD2FDD007BDB39; Path=/store
header.
Now the code is something like:
public class FrontController extends HttpServlet {
public void
(request, response,
principal, authType, username, password). When it accesses the HTTP session the
Response is instructed to send Set-Cookie with a newly generated JSESSIONID and
immediately after that - as part of the register method invocation - the
Request is instructed to change the
-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.ha
> 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
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("
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
HttpServlet
> 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 thos
> 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
pla
> 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
> 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
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 interc
> 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 w
-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
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
> 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 t
> 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 diffe
ey 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 (d
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
> > 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
-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-Co
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
e number of sessions again... 2 sessions!
I believe the problem is that Tomcat does not send the Set-Cookie
information with JSESSIONID in it if the Filter is present. Without the
filter, there is only single session across the requests (like it should
be).
FYI: We are using Tomcat 5.5. The s
45 matches
Mail list logo
