You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Daniel Watrous <da...@gmail.com> on 2011/05/27 07:47:28 UTC

cookie manager not working

Hello,

I've been trying to setup a jmeter program to test a wordpress plugin.
However, I can't get the login to work. It appears to be sending the
cookies back correctly when the login is sent, but they don't get
picked up by the cookie manager.

I've been searching for a while and looked at dozens of examples.
Maybe you can spot what I've done wrong from these screenshots:

http://screencast.com/t/EW1zAgvlK
http://screencast.com/t/2i8dTyBh
http://screencast.com/t/fd5dGPvCb

Thanks in advance.

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Daniel Watrous <da...@gmail.com>.
I think it's a bit premature to suggest that WordPress is broken. It
is used on tens of millions of sites and people are able to login fine
every day.

Is there a jobs board for jmeter where I could hire a guru to get my
tests going?

Daniel

On Thu, Jun 2, 2011 at 9:35 AM, Bruce Ide <fl...@gmail.com> wrote:
> Jmeter's doing the right thing. If you're testing wordpress, file a bug with
> them and tell them to fix their thing. If you're running an application
> server yourself, I'd suspect it's something wrong with your application
> server config.
>
> You have the jmeter source, you could always change its behavior to do what
> you want and recompile it. I'd start with CookieManager.java:
>
>        while (cookies.hasNext()) {
>            Cookie cook = (Cookie) cookies.next().getObjectValue();
>            final long expiresMillis = cook.getExpiresMillis();
>            if (expiresMillis == 0 || expiresMillis > now) { // only save
> unexpired cookies
>                writer.println(cookieToString(cook));
>            }
>        }
>
> Well there's your problem! I can't guarantee that's the only thing that
> prevents expired cookies from being sent. I suspect there's probably also
> some code in httpclient that checks to see if they're expired before sending
> them back.
>
> I'd be really hesitant to change the behavior of the test environment to
> mask a bug you uncovered, though. Sending expired cookies IS a bug, and it's
> something the guys running the server should fix.
>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 3 June 2011 02:48, sebb <se...@gmail.com> wrote:
> On 3 June 2011 02:32, Deepak Shetty <sh...@gmail.com> wrote:
>> Ok i will . Visually the cookies look fine and one of them does get sent in
>> the next request (the one without path and http only)
>
> When I try, I get several cookies rejected, e.g. with the message:
>
> (Illegal path attribute "/testjmeter/wp-admin". Path of origin:
> "/testjmeter/wp-login.php")
>
> Maybe that is part of the problem?

I'd forgotten - there is a JMeter property one can set to avoid
checking cookies for validity:

CookieManager.check.cookies=false

Setting that prevents the invalid cookie paths from being rejected.

>> Daniel : see if
>> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
>> for you. I added the missing cookie programattically (various
>> hardcodes but you shoould be able to login - logout doesnt work because I
>> need to remove the cookie i set)
>>
>> regards
>> deepak
>>
>> On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
>>> > There seems to be a Jmeter Bug
>>> >
>>> > Login request gets the following as response
>>> >
>>> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
>>> > Set-Cookie:
>>> >
>>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>>> > path=/testjmeter/wp-content/plugins; httponly
>>> > *Set-Cookie:
>>> >
>>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>>> > path=/testjmeter/wp-admin; httponly
>>> > *Set-Cookie:
>>> >
>>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
>>> >
>>> > All good here
>>>
>>> Perhaps not - please enable Cookie Manager Debug logging to see if any
>>> of the cookies have been rejected, and why.
>>>
>>> > The next request
>>> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
>>> > Cookie Data:
>>> > wordpress_test_cookie=WP+Cookie+check;
>>> >
>>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
>>> >
>>> > doesnt have the cookie above  that I bolded which has an explicit path
>>> and
>>> > httponly (not sure which of the attributes cause a problem)
>>> >
>>> > Programatically setting the cookies seem to be the only workaround
>>> without
>>> > code fix, can you please confirm (I dont think expiry date has naything
>>> to
>>> > do with , like you say , past expiry is used to delete a cookie)
>>> > regards
>>> > deepak
>>> >
>>> >
>>> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
>>> >
>>> >> Yes; perhaps it is deliberately sending expired dates in order to
>>> >> delete the cookies. I have seen another server do this.
>>> >>
>>> >> From some biref experiments with your test site, I suspect the login
>>> >> problem is nothing to do with expired cookies after all, but there is
>>> >> probably some other setting that is not correct.
>>> >>
>>> >> Look for parameters that have odd-looking values; they may be being
>>> >> set by Javascript in the browser, in which case you will have to work
>>> >> out how to extract the relevant values from the previous reponse.
>>> >>
>>> >> Or record the login twice, and compare the generated test plans to see
>>> >> which entries have changed. You then have to work out how to extract
>>> >> the values they need. The Save Responses to a File Listener can be
>>> >> helpful here.
>>> >>
>>> >> BTW, JMeter cannot currently handle deflate encoding, so make sure you
>>> >> don't enable that in the Header Manager.
>>> >>
>>> >> Also, Excludes *do* work - make sure that there aren't any trailing
>>> >> spaces or other spurious characters in the fields.
>>> >>
>>> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com> wrote:
>>> >> > Did any of you notice that the Date of the request is accurate and so
>>> >> > are some of the cookies? WordPress seems to deliberately send the
>>> >> > login related cookies with the year old expiration. Others are fine.
>>> >> >
>>> >> > I mention this because there seems to be an idea that the server time
>>> >> > is configured wrong.
>>> >> >
>>> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
>>> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
>>> >> >>>  > I think it's a bit premature to suggest that WordPress is broken.
>>> It
>>> >> >>>  > is used on tens of millions of sites and people are able to login
>>> >> fine
>>> >> >>>  >every day.
>>> >> >>>
>>> >> >>> Number of users is not a quality metric! Look at Windows... (Heh heh
>>> >> heh)
>>> >> >>>
>>> >> >>>> Well there's your problem!
>>> >> >>>>
>>> >> >>>> That only affects the cookies that are stored in the cookies file
>>> >> >>>> (which is not normally used).
>>> >> >>>>
>>> >> >>>>
>>> >> >>> Doh! It seemed like such a likely culprit, too!
>>> >> >>>
>>> >> >>
>>> >> >> The actual expiry code is similar:
>>> >> >>
>>> >> >>                // Store session cookies as well as unexpired ones
>>> >> >>                if (exp == 0 || exp >= System.currentTimeMillis()) {
>>> >> >>                    newCookie.setVersion(cookie.getVersion());
>>> >> >>                    add(newCookie); // Has its own debug log; removes
>>> >> >> matching cookies
>>> >> >>                } else {
>>> >> >>                    removeMatchingCookies(newCookie);
>>> >> >>                    if (debugEnabled){
>>> >> >>                        log.debug("Dropping expired Cookie:
>>> >> >> "+newCookie.toString());
>>> >> >>                    }
>>> >> >>                }
>>> >> >>
>>> >> >>
>>> >> >>>
>>> >> >>>> > I'd be really hesitant to change the behavior of the test
>>> >> environment to
>>> >> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a
>>> bug,
>>> >> and
>>> >> >>>> it's
>>> >> >>>> > something the guys running the server should fix.
>>> >> >>>>
>>> >> >>>> If this is a general problem, I suppose it might make sense to add
>>> an
>>> >> >>>> option to remove the expiry date from stale cookies, turning them
>>> into
>>> >> >>>> session cookies.
>>> >> >>>> But AFAIK this is the first time this has been reported [, and
>>> might
>>> >> >>>> cause indigestion (!) in some cases].
>>> >> >>>>
>>> >> >>>>
>>> >> >>> Well it sounds like the web browser is also storing and using the
>>> >> expired
>>> >> >>> cookie, and the remote server is honoring it! That's like 3
>>> different
>>> >> bugs
>>> >> >>> he's uncovered so far! At this point I'd be rampaging like...
>>> something
>>> >> that
>>> >> >>> rampages a LOT... through 2 or 3 different bug forums.
>>> >> >>>
>>> >> >>> I'm sure the Firefox guys would say "No it's not!" At least some
>>> people
>>> >> in
>>> >> >>> the "real world" do check cookie expiry dates, but it's probably
>>> >> "optional".
>>> >> >>> I'm not inclined to go digging through RFCs to find out.
>>> >> >>>
>>> >> >>> I'd say Wordpress sending out cookies from last year means someone
>>> >> hasn't
>>> >> >>> been minding a server like they should be. That really IS a problem.
>>> >> >>
>>> >> >> Agreed.
>>> >> >>
>>> >> >>> I suppose you could add a "Remove expiration dates" to the cookie
>>> >> manager
>>> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
>>> Probably
>>> >> >>> wouldn't be a huge amount of coding, and would probably be only
>>> vaguely
>>> >> >>> atrocious.
>>> >> >>
>>> >> >> It's fairly simple to change the code itself, but there is additional
>>> >> >> work needed to implement the GUI change and update the documentation.
>>> >> >>
>>> >> >> It's not yet clear if this is a general problem affecting multiple
>>> >> >> servers, or just WordPress servers, or just an issue with the
>>> >> >> particular WordPress host.
>>> >> >>
>>> >> >>> Or perhaps a sampler or postprocessor that allows you to manipulate
>>> >> explicit
>>> >> >>> cookie values? That'd be a bit more work, but might be more
>>> palatable.
>>> >> >>
>>> >> >> That can be done already with the Regex Processor and Header Manager,
>>> >> >> or using the BSH or BSF test elements.
>>> >> >>
>>> >> >> Might just be simpler to change the time on the box running JMeter
>>> ...
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >> >
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
I guess my confusion arises because most of the text talks about restricting
the scope of the cookies and the RFC only allows you to broaden the scope.In
any case the workaround is more than sufficient for these cases

regards
deepak


On Fri, Jun 3, 2011 at 1:05 PM, sebb <se...@gmail.com> wrote:

> On 3 June 2011 20:36, Deepak Shetty <sh...@gmail.com> wrote:
> > even www.wordpress.com does the same thing and it seems to work fine in
> FF
> >
> > *https://en.wordpress.com/wp-login.php*
> > POST /wp-login.php HTTP/1.1
> > Set-Cookie: wordpress=VALUE; expires=Fri, 17-Jun-2011 19:32:09 GMT; *
> > path=/wp-admin;* domain=.wordpress.com; httponly
> >
> > the browser is at url "/" , the post is to url */wp-login.php *- what is
> the
> > path to be compared with - the url the browser is at or the URL that is
> > being posted to. ?
>
> AIUI, the cookie path is to be compared with the current request URI,
> i.e. /wp-login.php
>
> >
> > regards
> > deepak
> >
> >
> > On Fri, Jun 3, 2011 at 4:26 AM, sebb <se...@gmail.com> wrote:
> >
> >> On 3 June 2011 04:27, Deepak Shetty <sh...@gmail.com> wrote:
> >> > You are right , that is the problem . However im wondering what the
> right
> >> > behavior is
> >> > If I request "/testjmeter/wp-login.php"
> >> > Then arent these valid paths for set-cookie
> >> > /
> >> > /testjmeter
> >> > /testjmeter/wp-login.php
> >> > /testjmeter/child/  --> This is the problematic one. I was under the
> >> > impression this was allowed?
> >>
> >> The Netscape specs (such as they are) are not entirely clear on this.
> >> I have found the following:
> >>
> >> [1] the pathname component of the URL is compared with the path
> >> attribute, and if there is a match, the cookie is considered valid and
> >> is sent along with the URL request. The path "/foo" would match
> >> "/foobar" and "/foo/bar.html". The path "/" is the most general path.
> >>
> >> RFC2109 says cookies should be rejected if "The value for the Path
> >> attribute is not a prefix of the request-URI."
> >>
> >> My reading is that  /testjmeter/child/ is not allowed by either cookie
> >> spec.
> >>
> >> > if my page is at the root /wp-login.php then I think all directories
> >> under /
> >> > are allowed in the Set-Cookie?
> >>
> >> If the path is set to /, then all files and directories under it are
> >> allowed.
> >> However, as far as I can tell, if the path is set to /wp-login.php
> >> then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
> >> that exists)
> >>
> >> > I tried to look through the cookie RFC and didnt seem to find
> information
> >> > one way or the other
> >>
> >> See above.
> >>
> >> > I can verify your fix works
> >> > CookieManager.check.cookies=false -- Daniel this should work without
> >> needing
> >> > to manipulate cookies (In my example set this in jmeter.properties and
> >> > disable the pre processor that adds the cookie)
> >>
> >> Best to add this to user.properties
> >>
> >> [1] http://curl.haxx.se/rfc/cookie_spec.html
> >> [2]
> >>
> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 3 June 2011 20:36, Deepak Shetty <sh...@gmail.com> wrote:
> even www.wordpress.com does the same thing and it seems to work fine in FF
>
> *https://en.wordpress.com/wp-login.php*
> POST /wp-login.php HTTP/1.1
> Set-Cookie: wordpress=VALUE; expires=Fri, 17-Jun-2011 19:32:09 GMT; *
> path=/wp-admin;* domain=.wordpress.com; httponly
>
> the browser is at url "/" , the post is to url */wp-login.php *- what is the
> path to be compared with - the url the browser is at or the URL that is
> being posted to. ?

AIUI, the cookie path is to be compared with the current request URI,
i.e. /wp-login.php

>
> regards
> deepak
>
>
> On Fri, Jun 3, 2011 at 4:26 AM, sebb <se...@gmail.com> wrote:
>
>> On 3 June 2011 04:27, Deepak Shetty <sh...@gmail.com> wrote:
>> > You are right , that is the problem . However im wondering what the right
>> > behavior is
>> > If I request "/testjmeter/wp-login.php"
>> > Then arent these valid paths for set-cookie
>> > /
>> > /testjmeter
>> > /testjmeter/wp-login.php
>> > /testjmeter/child/  --> This is the problematic one. I was under the
>> > impression this was allowed?
>>
>> The Netscape specs (such as they are) are not entirely clear on this.
>> I have found the following:
>>
>> [1] the pathname component of the URL is compared with the path
>> attribute, and if there is a match, the cookie is considered valid and
>> is sent along with the URL request. The path "/foo" would match
>> "/foobar" and "/foo/bar.html". The path "/" is the most general path.
>>
>> RFC2109 says cookies should be rejected if "The value for the Path
>> attribute is not a prefix of the request-URI."
>>
>> My reading is that  /testjmeter/child/ is not allowed by either cookie
>> spec.
>>
>> > if my page is at the root /wp-login.php then I think all directories
>> under /
>> > are allowed in the Set-Cookie?
>>
>> If the path is set to /, then all files and directories under it are
>> allowed.
>> However, as far as I can tell, if the path is set to /wp-login.php
>> then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
>> that exists)
>>
>> > I tried to look through the cookie RFC and didnt seem to find information
>> > one way or the other
>>
>> See above.
>>
>> > I can verify your fix works
>> > CookieManager.check.cookies=false -- Daniel this should work without
>> needing
>> > to manipulate cookies (In my example set this in jmeter.properties and
>> > disable the pre processor that adds the cookie)
>>
>> Best to add this to user.properties
>>
>> [1] http://curl.haxx.se/rfc/cookie_spec.html
>> [2]
>> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
even www.wordpress.com does the same thing and it seems to work fine in FF

*https://en.wordpress.com/wp-login.php*
POST /wp-login.php HTTP/1.1
Set-Cookie: wordpress=VALUE; expires=Fri, 17-Jun-2011 19:32:09 GMT; *
path=/wp-admin;* domain=.wordpress.com; httponly

the browser is at url "/" , the post is to url */wp-login.php *- what is the
path to be compared with - the url the browser is at or the URL that is
being posted to. ?


regards
deepak


On Fri, Jun 3, 2011 at 4:26 AM, sebb <se...@gmail.com> wrote:

> On 3 June 2011 04:27, Deepak Shetty <sh...@gmail.com> wrote:
> > You are right , that is the problem . However im wondering what the right
> > behavior is
> > If I request "/testjmeter/wp-login.php"
> > Then arent these valid paths for set-cookie
> > /
> > /testjmeter
> > /testjmeter/wp-login.php
> > /testjmeter/child/  --> This is the problematic one. I was under the
> > impression this was allowed?
>
> The Netscape specs (such as they are) are not entirely clear on this.
> I have found the following:
>
> [1] the pathname component of the URL is compared with the path
> attribute, and if there is a match, the cookie is considered valid and
> is sent along with the URL request. The path "/foo" would match
> "/foobar" and "/foo/bar.html". The path "/" is the most general path.
>
> RFC2109 says cookies should be rejected if "The value for the Path
> attribute is not a prefix of the request-URI."
>
> My reading is that  /testjmeter/child/ is not allowed by either cookie
> spec.
>
> > if my page is at the root /wp-login.php then I think all directories
> under /
> > are allowed in the Set-Cookie?
>
> If the path is set to /, then all files and directories under it are
> allowed.
> However, as far as I can tell, if the path is set to /wp-login.php
> then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
> that exists)
>
> > I tried to look through the cookie RFC and didnt seem to find information
> > one way or the other
>
> See above.
>
> > I can verify your fix works
> > CookieManager.check.cookies=false -- Daniel this should work without
> needing
> > to manipulate cookies (In my example set this in jmeter.properties and
> > disable the pre processor that adds the cookie)
>
> Best to add this to user.properties
>
> [1] http://curl.haxx.se/rfc/cookie_spec.html
> [2]
> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 3 June 2011 04:27, Deepak Shetty <sh...@gmail.com> wrote:
> You are right , that is the problem . However im wondering what the right
> behavior is
> If I request "/testjmeter/wp-login.php"
> Then arent these valid paths for set-cookie
> /
> /testjmeter
> /testjmeter/wp-login.php
> /testjmeter/child/  --> This is the problematic one. I was under the
> impression this was allowed?

The Netscape specs (such as they are) are not entirely clear on this.
I have found the following:

[1] the pathname component of the URL is compared with the path
attribute, and if there is a match, the cookie is considered valid and
is sent along with the URL request. The path "/foo" would match
"/foobar" and "/foo/bar.html". The path "/" is the most general path.

RFC2109 says cookies should be rejected if "The value for the Path
attribute is not a prefix of the request-URI."

My reading is that  /testjmeter/child/ is not allowed by either cookie spec.

> if my page is at the root /wp-login.php then I think all directories under /
> are allowed in the Set-Cookie?

If the path is set to /, then all files and directories under it are allowed.
However, as far as I can tell, if the path is set to /wp-login.php
then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
that exists)

> I tried to look through the cookie RFC and didnt seem to find information
> one way or the other

See above.

> I can verify your fix works
> CookieManager.check.cookies=false -- Daniel this should work without needing
> to manipulate cookies (In my example set this in jmeter.properties and
> disable the pre processor that adds the cookie)

Best to add this to user.properties

[1] http://curl.haxx.se/rfc/cookie_spec.html
[2] http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
>Can anyone tell me why my exclude definitions on the proxy didn't
>exclude the files I expected?
Sorry I dont see where this question is? Its probably best to start a new
thread.

On Thu, Jun 2, 2011 at 9:01 PM, Daniel Watrous <da...@gmail.com>wrote:

> Thank You.
>
> This works wonderfully. It's exactly what I was hoping to be able to
> accomplish. You all really went the extra mile to help me out.
>
> Can anyone tell me why my exclude definitions on the proxy didn't
> exclude the files I expected?
>
> Daniel
>
> On Thu, Jun 2, 2011 at 9:27 PM, Deepak Shetty <sh...@gmail.com> wrote:
> > You are right , that is the problem . However im wondering what the right
> > behavior is
> > If I request "/testjmeter/wp-login.php"
> > Then arent these valid paths for set-cookie
> > /
> > /testjmeter
> > /testjmeter/wp-login.php
> > /testjmeter/child/  --> This is the problematic one. I was under the
> > impression this was allowed?
> >
> > if my page is at the root /wp-login.php then I think all directories
> under /
> > are allowed in the Set-Cookie?
> >
> > I tried to look through the cookie RFC and didnt seem to find information
> > one way or the other
> >
> > I can verify your fix works
> > CookieManager.check.cookies=false -- Daniel this should work without
> needing
> > to manipulate cookies (In my example set this in jmeter.properties and
> > disable the pre processor that adds the cookie)
> >
> >
> >
> > regards
> > deepak
> >
> >
> >
> >
> >
> >
> > On Thu, Jun 2, 2011 at 6:48 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 3 June 2011 02:32, Deepak Shetty <sh...@gmail.com> wrote:
> >> > Ok i will . Visually the cookies look fine and one of them does get
> sent
> >> in
> >> > the next request (the one without path and http only)
> >>
> >> When I try, I get several cookies rejected, e.g. with the message:
> >>
> >> (Illegal path attribute "/testjmeter/wp-admin". Path of origin:
> >> "/testjmeter/wp-login.php")
> >>
> >> Maybe that is part of the problem?
> >>
> >> > Daniel : see if
> >> >
> >>
> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
> >> > for you. I added the missing cookie programattically (various
> >> > hardcodes but you shoould be able to login - logout doesnt work
> because I
> >> > need to remove the cookie i set)
> >> >
> >> > regards
> >> > deepak
> >> >
> >> > On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:
> >> >
> >> >> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
> >> >> > There seems to be a Jmeter Bug
> >> >> >
> >> >> > Login request gets the following as response
> >> >> >
> >> >> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check;
> path=/testjmeter/
> >> >> > Set-Cookie:
> >> >> >
> >> >>
> >>
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> >> >> > path=/testjmeter/wp-content/plugins; httponly
> >> >> > *Set-Cookie:
> >> >> >
> >> >>
> >>
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> >> >> > path=/testjmeter/wp-admin; httponly
> >> >> > *Set-Cookie:
> >> >> >
> >> >>
> >>
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
> >> >> >
> >> >> > All good here
> >> >>
> >> >> Perhaps not - please enable Cookie Manager Debug logging to see if
> any
> >> >> of the cookies have been rejected, and why.
> >> >>
> >> >> > The next request
> >> >> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
> >> >> > Cookie Data:
> >> >> > wordpress_test_cookie=WP+Cookie+check;
> >> >> >
> >> >>
> >>
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
> >> >> >
> >> >> > doesnt have the cookie above  that I bolded which has an explicit
> path
> >> >> and
> >> >> > httponly (not sure which of the attributes cause a problem)
> >> >> >
> >> >> > Programatically setting the cookies seem to be the only workaround
> >> >> without
> >> >> > code fix, can you please confirm (I dont think expiry date has
> >> naything
> >> >> to
> >> >> > do with , like you say , past expiry is used to delete a cookie)
> >> >> > regards
> >> >> > deepak
> >> >> >
> >> >> >
> >> >> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
> >> >> >
> >> >> >> Yes; perhaps it is deliberately sending expired dates in order to
> >> >> >> delete the cookies. I have seen another server do this.
> >> >> >>
> >> >> >> From some biref experiments with your test site, I suspect the
> login
> >> >> >> problem is nothing to do with expired cookies after all, but there
> is
> >> >> >> probably some other setting that is not correct.
> >> >> >>
> >> >> >> Look for parameters that have odd-looking values; they may be
> being
> >> >> >> set by Javascript in the browser, in which case you will have to
> work
> >> >> >> out how to extract the relevant values from the previous reponse.
> >> >> >>
> >> >> >> Or record the login twice, and compare the generated test plans to
> >> see
> >> >> >> which entries have changed. You then have to work out how to
> extract
> >> >> >> the values they need. The Save Responses to a File Listener can be
> >> >> >> helpful here.
> >> >> >>
> >> >> >> BTW, JMeter cannot currently handle deflate encoding, so make sure
> >> you
> >> >> >> don't enable that in the Header Manager.
> >> >> >>
> >> >> >> Also, Excludes *do* work - make sure that there aren't any
> trailing
> >> >> >> spaces or other spurious characters in the fields.
> >> >> >>
> >> >> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com>
> >> wrote:
> >> >> >> > Did any of you notice that the Date of the request is accurate
> and
> >> so
> >> >> >> > are some of the cookies? WordPress seems to deliberately send
> the
> >> >> >> > login related cookies with the year old expiration. Others are
> >> fine.
> >> >> >> >
> >> >> >> > I mention this because there seems to be an idea that the server
> >> time
> >> >> >> > is configured wrong.
> >> >> >> >
> >> >> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
> >> >> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com>
> >> wrote:
> >> >> >> >>>  > I think it's a bit premature to suggest that WordPress is
> >> broken.
> >> >> It
> >> >> >> >>>  > is used on tens of millions of sites and people are able to
> >> login
> >> >> >> fine
> >> >> >> >>>  >every day.
> >> >> >> >>>
> >> >> >> >>> Number of users is not a quality metric! Look at Windows...
> (Heh
> >> heh
> >> >> >> heh)
> >> >> >> >>>
> >> >> >> >>>> Well there's your problem!
> >> >> >> >>>>
> >> >> >> >>>> That only affects the cookies that are stored in the cookies
> >> file
> >> >> >> >>>> (which is not normally used).
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>> Doh! It seemed like such a likely culprit, too!
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >> The actual expiry code is similar:
> >> >> >> >>
> >> >> >> >>                // Store session cookies as well as unexpired
> ones
> >> >> >> >>                if (exp == 0 || exp >=
> System.currentTimeMillis())
> >> {
> >> >> >> >>                    newCookie.setVersion(cookie.getVersion());
> >> >> >> >>                    add(newCookie); // Has its own debug log;
> >> removes
> >> >> >> >> matching cookies
> >> >> >> >>                } else {
> >> >> >> >>                    removeMatchingCookies(newCookie);
> >> >> >> >>                    if (debugEnabled){
> >> >> >> >>                        log.debug("Dropping expired Cookie:
> >> >> >> >> "+newCookie.toString());
> >> >> >> >>                    }
> >> >> >> >>                }
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>>
> >> >> >> >>>> > I'd be really hesitant to change the behavior of the test
> >> >> >> environment to
> >> >> >> >>>> > mask a bug you uncovered, though. Sending expired cookies
> IS a
> >> >> bug,
> >> >> >> and
> >> >> >> >>>> it's
> >> >> >> >>>> > something the guys running the server should fix.
> >> >> >> >>>>
> >> >> >> >>>> If this is a general problem, I suppose it might make sense
> to
> >> add
> >> >> an
> >> >> >> >>>> option to remove the expiry date from stale cookies, turning
> >> them
> >> >> into
> >> >> >> >>>> session cookies.
> >> >> >> >>>> But AFAIK this is the first time this has been reported [,
> and
> >> >> might
> >> >> >> >>>> cause indigestion (!) in some cases].
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>> Well it sounds like the web browser is also storing and using
> the
> >> >> >> expired
> >> >> >> >>> cookie, and the remote server is honoring it! That's like 3
> >> >> different
> >> >> >> bugs
> >> >> >> >>> he's uncovered so far! At this point I'd be rampaging like...
> >> >> something
> >> >> >> that
> >> >> >> >>> rampages a LOT... through 2 or 3 different bug forums.
> >> >> >> >>>
> >> >> >> >>> I'm sure the Firefox guys would say "No it's not!" At least
> some
> >> >> people
> >> >> >> in
> >> >> >> >>> the "real world" do check cookie expiry dates, but it's
> probably
> >> >> >> "optional".
> >> >> >> >>> I'm not inclined to go digging through RFCs to find out.
> >> >> >> >>>
> >> >> >> >>> I'd say Wordpress sending out cookies from last year means
> >> someone
> >> >> >> hasn't
> >> >> >> >>> been minding a server like they should be. That really IS a
> >> problem.
> >> >> >> >>
> >> >> >> >> Agreed.
> >> >> >> >>
> >> >> >> >>> I suppose you could add a "Remove expiration dates" to the
> cookie
> >> >> >> manager
> >> >> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
> >> >> Probably
> >> >> >> >>> wouldn't be a huge amount of coding, and would probably be
> only
> >> >> vaguely
> >> >> >> >>> atrocious.
> >> >> >> >>
> >> >> >> >> It's fairly simple to change the code itself, but there is
> >> additional
> >> >> >> >> work needed to implement the GUI change and update the
> >> documentation.
> >> >> >> >>
> >> >> >> >> It's not yet clear if this is a general problem affecting
> multiple
> >> >> >> >> servers, or just WordPress servers, or just an issue with the
> >> >> >> >> particular WordPress host.
> >> >> >> >>
> >> >> >> >>> Or perhaps a sampler or postprocessor that allows you to
> >> manipulate
> >> >> >> explicit
> >> >> >> >>> cookie values? That'd be a bit more work, but might be more
> >> >> palatable.
> >> >> >> >>
> >> >> >> >> That can be done already with the Regex Processor and Header
> >> Manager,
> >> >> >> >> or using the BSH or BSF test elements.
> >> >> >> >>
> >> >> >> >> Might just be simpler to change the time on the box running
> JMeter
> >> >> ...
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail:
> >> jmeter-user-unsubscribe@jakarta.apache.org
> >> >> >> >> For additional commands, e-mail:
> >> jmeter-user-help@jakarta.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> >> >> >> > For additional commands, e-mail:
> >> jmeter-user-help@jakarta.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> >> >> >> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 3 June 2011 05:01, Daniel Watrous <da...@gmail.com> wrote:
> Thank You.
>
> This works wonderfully. It's exactly what I was hoping to be able to
> accomplish. You all really went the extra mile to help me out.
>
> Can anyone tell me why my exclude definitions on the proxy didn't
> exclude the files I expected?

I already answered that. Probably spurious characters in the regexes.

BTW, you can select the Workbench and save it to a file, then Merge it later.

> Daniel
>
> On Thu, Jun 2, 2011 at 9:27 PM, Deepak Shetty <sh...@gmail.com> wrote:
>> You are right , that is the problem . However im wondering what the right
>> behavior is
>> If I request "/testjmeter/wp-login.php"
>> Then arent these valid paths for set-cookie
>> /
>> /testjmeter
>> /testjmeter/wp-login.php
>> /testjmeter/child/  --> This is the problematic one. I was under the
>> impression this was allowed?
>>
>> if my page is at the root /wp-login.php then I think all directories under /
>> are allowed in the Set-Cookie?
>>
>> I tried to look through the cookie RFC and didnt seem to find information
>> one way or the other
>>
>> I can verify your fix works
>> CookieManager.check.cookies=false -- Daniel this should work without needing
>> to manipulate cookies (In my example set this in jmeter.properties and
>> disable the pre processor that adds the cookie)
>>
>>
>>
>> regards
>> deepak
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 2, 2011 at 6:48 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 3 June 2011 02:32, Deepak Shetty <sh...@gmail.com> wrote:
>>> > Ok i will . Visually the cookies look fine and one of them does get sent
>>> in
>>> > the next request (the one without path and http only)
>>>
>>> When I try, I get several cookies rejected, e.g. with the message:
>>>
>>> (Illegal path attribute "/testjmeter/wp-admin". Path of origin:
>>> "/testjmeter/wp-login.php")
>>>
>>> Maybe that is part of the problem?
>>>
>>> > Daniel : see if
>>> >
>>> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
>>> > for you. I added the missing cookie programattically (various
>>> > hardcodes but you shoould be able to login - logout doesnt work because I
>>> > need to remove the cookie i set)
>>> >
>>> > regards
>>> > deepak
>>> >
>>> > On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:
>>> >
>>> >> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
>>> >> > There seems to be a Jmeter Bug
>>> >> >
>>> >> > Login request gets the following as response
>>> >> >
>>> >> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
>>> >> > Set-Cookie:
>>> >> >
>>> >>
>>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>>> >> > path=/testjmeter/wp-content/plugins; httponly
>>> >> > *Set-Cookie:
>>> >> >
>>> >>
>>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>>> >> > path=/testjmeter/wp-admin; httponly
>>> >> > *Set-Cookie:
>>> >> >
>>> >>
>>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
>>> >> >
>>> >> > All good here
>>> >>
>>> >> Perhaps not - please enable Cookie Manager Debug logging to see if any
>>> >> of the cookies have been rejected, and why.
>>> >>
>>> >> > The next request
>>> >> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
>>> >> > Cookie Data:
>>> >> > wordpress_test_cookie=WP+Cookie+check;
>>> >> >
>>> >>
>>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
>>> >> >
>>> >> > doesnt have the cookie above  that I bolded which has an explicit path
>>> >> and
>>> >> > httponly (not sure which of the attributes cause a problem)
>>> >> >
>>> >> > Programatically setting the cookies seem to be the only workaround
>>> >> without
>>> >> > code fix, can you please confirm (I dont think expiry date has
>>> naything
>>> >> to
>>> >> > do with , like you say , past expiry is used to delete a cookie)
>>> >> > regards
>>> >> > deepak
>>> >> >
>>> >> >
>>> >> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
>>> >> >
>>> >> >> Yes; perhaps it is deliberately sending expired dates in order to
>>> >> >> delete the cookies. I have seen another server do this.
>>> >> >>
>>> >> >> From some biref experiments with your test site, I suspect the login
>>> >> >> problem is nothing to do with expired cookies after all, but there is
>>> >> >> probably some other setting that is not correct.
>>> >> >>
>>> >> >> Look for parameters that have odd-looking values; they may be being
>>> >> >> set by Javascript in the browser, in which case you will have to work
>>> >> >> out how to extract the relevant values from the previous reponse.
>>> >> >>
>>> >> >> Or record the login twice, and compare the generated test plans to
>>> see
>>> >> >> which entries have changed. You then have to work out how to extract
>>> >> >> the values they need. The Save Responses to a File Listener can be
>>> >> >> helpful here.
>>> >> >>
>>> >> >> BTW, JMeter cannot currently handle deflate encoding, so make sure
>>> you
>>> >> >> don't enable that in the Header Manager.
>>> >> >>
>>> >> >> Also, Excludes *do* work - make sure that there aren't any trailing
>>> >> >> spaces or other spurious characters in the fields.
>>> >> >>
>>> >> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com>
>>> wrote:
>>> >> >> > Did any of you notice that the Date of the request is accurate and
>>> so
>>> >> >> > are some of the cookies? WordPress seems to deliberately send the
>>> >> >> > login related cookies with the year old expiration. Others are
>>> fine.
>>> >> >> >
>>> >> >> > I mention this because there seems to be an idea that the server
>>> time
>>> >> >> > is configured wrong.
>>> >> >> >
>>> >> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
>>> >> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com>
>>> wrote:
>>> >> >> >>>  > I think it's a bit premature to suggest that WordPress is
>>> broken.
>>> >> It
>>> >> >> >>>  > is used on tens of millions of sites and people are able to
>>> login
>>> >> >> fine
>>> >> >> >>>  >every day.
>>> >> >> >>>
>>> >> >> >>> Number of users is not a quality metric! Look at Windows... (Heh
>>> heh
>>> >> >> heh)
>>> >> >> >>>
>>> >> >> >>>> Well there's your problem!
>>> >> >> >>>>
>>> >> >> >>>> That only affects the cookies that are stored in the cookies
>>> file
>>> >> >> >>>> (which is not normally used).
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>> Doh! It seemed like such a likely culprit, too!
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >> The actual expiry code is similar:
>>> >> >> >>
>>> >> >> >>                // Store session cookies as well as unexpired ones
>>> >> >> >>                if (exp == 0 || exp >= System.currentTimeMillis())
>>> {
>>> >> >> >>                    newCookie.setVersion(cookie.getVersion());
>>> >> >> >>                    add(newCookie); // Has its own debug log;
>>> removes
>>> >> >> >> matching cookies
>>> >> >> >>                } else {
>>> >> >> >>                    removeMatchingCookies(newCookie);
>>> >> >> >>                    if (debugEnabled){
>>> >> >> >>                        log.debug("Dropping expired Cookie:
>>> >> >> >> "+newCookie.toString());
>>> >> >> >>                    }
>>> >> >> >>                }
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>>
>>> >> >> >>>> > I'd be really hesitant to change the behavior of the test
>>> >> >> environment to
>>> >> >> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a
>>> >> bug,
>>> >> >> and
>>> >> >> >>>> it's
>>> >> >> >>>> > something the guys running the server should fix.
>>> >> >> >>>>
>>> >> >> >>>> If this is a general problem, I suppose it might make sense to
>>> add
>>> >> an
>>> >> >> >>>> option to remove the expiry date from stale cookies, turning
>>> them
>>> >> into
>>> >> >> >>>> session cookies.
>>> >> >> >>>> But AFAIK this is the first time this has been reported [, and
>>> >> might
>>> >> >> >>>> cause indigestion (!) in some cases].
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>> Well it sounds like the web browser is also storing and using the
>>> >> >> expired
>>> >> >> >>> cookie, and the remote server is honoring it! That's like 3
>>> >> different
>>> >> >> bugs
>>> >> >> >>> he's uncovered so far! At this point I'd be rampaging like...
>>> >> something
>>> >> >> that
>>> >> >> >>> rampages a LOT... through 2 or 3 different bug forums.
>>> >> >> >>>
>>> >> >> >>> I'm sure the Firefox guys would say "No it's not!" At least some
>>> >> people
>>> >> >> in
>>> >> >> >>> the "real world" do check cookie expiry dates, but it's probably
>>> >> >> "optional".
>>> >> >> >>> I'm not inclined to go digging through RFCs to find out.
>>> >> >> >>>
>>> >> >> >>> I'd say Wordpress sending out cookies from last year means
>>> someone
>>> >> >> hasn't
>>> >> >> >>> been minding a server like they should be. That really IS a
>>> problem.
>>> >> >> >>
>>> >> >> >> Agreed.
>>> >> >> >>
>>> >> >> >>> I suppose you could add a "Remove expiration dates" to the cookie
>>> >> >> manager
>>> >> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
>>> >> Probably
>>> >> >> >>> wouldn't be a huge amount of coding, and would probably be only
>>> >> vaguely
>>> >> >> >>> atrocious.
>>> >> >> >>
>>> >> >> >> It's fairly simple to change the code itself, but there is
>>> additional
>>> >> >> >> work needed to implement the GUI change and update the
>>> documentation.
>>> >> >> >>
>>> >> >> >> It's not yet clear if this is a general problem affecting multiple
>>> >> >> >> servers, or just WordPress servers, or just an issue with the
>>> >> >> >> particular WordPress host.
>>> >> >> >>
>>> >> >> >>> Or perhaps a sampler or postprocessor that allows you to
>>> manipulate
>>> >> >> explicit
>>> >> >> >>> cookie values? That'd be a bit more work, but might be more
>>> >> palatable.
>>> >> >> >>
>>> >> >> >> That can be done already with the Regex Processor and Header
>>> Manager,
>>> >> >> >> or using the BSH or BSF test elements.
>>> >> >> >>
>>> >> >> >> Might just be simpler to change the time on the box running JMeter
>>> >> ...
>>> >> >> >>
>>> >> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> >> To unsubscribe, e-mail:
>>> jmeter-user-unsubscribe@jakarta.apache.org
>>> >> >> >> For additional commands, e-mail:
>>> jmeter-user-help@jakarta.apache.org
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> ---------------------------------------------------------------------
>>> >> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> >> > For additional commands, e-mail:
>>> jmeter-user-help@jakarta.apache.org
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Daniel Watrous <da...@gmail.com>.
Thank You.

This works wonderfully. It's exactly what I was hoping to be able to
accomplish. You all really went the extra mile to help me out.

Can anyone tell me why my exclude definitions on the proxy didn't
exclude the files I expected?

Daniel

On Thu, Jun 2, 2011 at 9:27 PM, Deepak Shetty <sh...@gmail.com> wrote:
> You are right , that is the problem . However im wondering what the right
> behavior is
> If I request "/testjmeter/wp-login.php"
> Then arent these valid paths for set-cookie
> /
> /testjmeter
> /testjmeter/wp-login.php
> /testjmeter/child/  --> This is the problematic one. I was under the
> impression this was allowed?
>
> if my page is at the root /wp-login.php then I think all directories under /
> are allowed in the Set-Cookie?
>
> I tried to look through the cookie RFC and didnt seem to find information
> one way or the other
>
> I can verify your fix works
> CookieManager.check.cookies=false -- Daniel this should work without needing
> to manipulate cookies (In my example set this in jmeter.properties and
> disable the pre processor that adds the cookie)
>
>
>
> regards
> deepak
>
>
>
>
>
>
> On Thu, Jun 2, 2011 at 6:48 PM, sebb <se...@gmail.com> wrote:
>
>> On 3 June 2011 02:32, Deepak Shetty <sh...@gmail.com> wrote:
>> > Ok i will . Visually the cookies look fine and one of them does get sent
>> in
>> > the next request (the one without path and http only)
>>
>> When I try, I get several cookies rejected, e.g. with the message:
>>
>> (Illegal path attribute "/testjmeter/wp-admin". Path of origin:
>> "/testjmeter/wp-login.php")
>>
>> Maybe that is part of the problem?
>>
>> > Daniel : see if
>> >
>> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
>> > for you. I added the missing cookie programattically (various
>> > hardcodes but you shoould be able to login - logout doesnt work because I
>> > need to remove the cookie i set)
>> >
>> > regards
>> > deepak
>> >
>> > On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
>> >> > There seems to be a Jmeter Bug
>> >> >
>> >> > Login request gets the following as response
>> >> >
>> >> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
>> >> > Set-Cookie:
>> >> >
>> >>
>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>> >> > path=/testjmeter/wp-content/plugins; httponly
>> >> > *Set-Cookie:
>> >> >
>> >>
>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>> >> > path=/testjmeter/wp-admin; httponly
>> >> > *Set-Cookie:
>> >> >
>> >>
>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
>> >> >
>> >> > All good here
>> >>
>> >> Perhaps not - please enable Cookie Manager Debug logging to see if any
>> >> of the cookies have been rejected, and why.
>> >>
>> >> > The next request
>> >> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
>> >> > Cookie Data:
>> >> > wordpress_test_cookie=WP+Cookie+check;
>> >> >
>> >>
>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
>> >> >
>> >> > doesnt have the cookie above  that I bolded which has an explicit path
>> >> and
>> >> > httponly (not sure which of the attributes cause a problem)
>> >> >
>> >> > Programatically setting the cookies seem to be the only workaround
>> >> without
>> >> > code fix, can you please confirm (I dont think expiry date has
>> naything
>> >> to
>> >> > do with , like you say , past expiry is used to delete a cookie)
>> >> > regards
>> >> > deepak
>> >> >
>> >> >
>> >> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
>> >> >
>> >> >> Yes; perhaps it is deliberately sending expired dates in order to
>> >> >> delete the cookies. I have seen another server do this.
>> >> >>
>> >> >> From some biref experiments with your test site, I suspect the login
>> >> >> problem is nothing to do with expired cookies after all, but there is
>> >> >> probably some other setting that is not correct.
>> >> >>
>> >> >> Look for parameters that have odd-looking values; they may be being
>> >> >> set by Javascript in the browser, in which case you will have to work
>> >> >> out how to extract the relevant values from the previous reponse.
>> >> >>
>> >> >> Or record the login twice, and compare the generated test plans to
>> see
>> >> >> which entries have changed. You then have to work out how to extract
>> >> >> the values they need. The Save Responses to a File Listener can be
>> >> >> helpful here.
>> >> >>
>> >> >> BTW, JMeter cannot currently handle deflate encoding, so make sure
>> you
>> >> >> don't enable that in the Header Manager.
>> >> >>
>> >> >> Also, Excludes *do* work - make sure that there aren't any trailing
>> >> >> spaces or other spurious characters in the fields.
>> >> >>
>> >> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com>
>> wrote:
>> >> >> > Did any of you notice that the Date of the request is accurate and
>> so
>> >> >> > are some of the cookies? WordPress seems to deliberately send the
>> >> >> > login related cookies with the year old expiration. Others are
>> fine.
>> >> >> >
>> >> >> > I mention this because there seems to be an idea that the server
>> time
>> >> >> > is configured wrong.
>> >> >> >
>> >> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
>> >> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com>
>> wrote:
>> >> >> >>>  > I think it's a bit premature to suggest that WordPress is
>> broken.
>> >> It
>> >> >> >>>  > is used on tens of millions of sites and people are able to
>> login
>> >> >> fine
>> >> >> >>>  >every day.
>> >> >> >>>
>> >> >> >>> Number of users is not a quality metric! Look at Windows... (Heh
>> heh
>> >> >> heh)
>> >> >> >>>
>> >> >> >>>> Well there's your problem!
>> >> >> >>>>
>> >> >> >>>> That only affects the cookies that are stored in the cookies
>> file
>> >> >> >>>> (which is not normally used).
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>> Doh! It seemed like such a likely culprit, too!
>> >> >> >>>
>> >> >> >>
>> >> >> >> The actual expiry code is similar:
>> >> >> >>
>> >> >> >>                // Store session cookies as well as unexpired ones
>> >> >> >>                if (exp == 0 || exp >= System.currentTimeMillis())
>> {
>> >> >> >>                    newCookie.setVersion(cookie.getVersion());
>> >> >> >>                    add(newCookie); // Has its own debug log;
>> removes
>> >> >> >> matching cookies
>> >> >> >>                } else {
>> >> >> >>                    removeMatchingCookies(newCookie);
>> >> >> >>                    if (debugEnabled){
>> >> >> >>                        log.debug("Dropping expired Cookie:
>> >> >> >> "+newCookie.toString());
>> >> >> >>                    }
>> >> >> >>                }
>> >> >> >>
>> >> >> >>
>> >> >> >>>
>> >> >> >>>> > I'd be really hesitant to change the behavior of the test
>> >> >> environment to
>> >> >> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a
>> >> bug,
>> >> >> and
>> >> >> >>>> it's
>> >> >> >>>> > something the guys running the server should fix.
>> >> >> >>>>
>> >> >> >>>> If this is a general problem, I suppose it might make sense to
>> add
>> >> an
>> >> >> >>>> option to remove the expiry date from stale cookies, turning
>> them
>> >> into
>> >> >> >>>> session cookies.
>> >> >> >>>> But AFAIK this is the first time this has been reported [, and
>> >> might
>> >> >> >>>> cause indigestion (!) in some cases].
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>> Well it sounds like the web browser is also storing and using the
>> >> >> expired
>> >> >> >>> cookie, and the remote server is honoring it! That's like 3
>> >> different
>> >> >> bugs
>> >> >> >>> he's uncovered so far! At this point I'd be rampaging like...
>> >> something
>> >> >> that
>> >> >> >>> rampages a LOT... through 2 or 3 different bug forums.
>> >> >> >>>
>> >> >> >>> I'm sure the Firefox guys would say "No it's not!" At least some
>> >> people
>> >> >> in
>> >> >> >>> the "real world" do check cookie expiry dates, but it's probably
>> >> >> "optional".
>> >> >> >>> I'm not inclined to go digging through RFCs to find out.
>> >> >> >>>
>> >> >> >>> I'd say Wordpress sending out cookies from last year means
>> someone
>> >> >> hasn't
>> >> >> >>> been minding a server like they should be. That really IS a
>> problem.
>> >> >> >>
>> >> >> >> Agreed.
>> >> >> >>
>> >> >> >>> I suppose you could add a "Remove expiration dates" to the cookie
>> >> >> manager
>> >> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
>> >> Probably
>> >> >> >>> wouldn't be a huge amount of coding, and would probably be only
>> >> vaguely
>> >> >> >>> atrocious.
>> >> >> >>
>> >> >> >> It's fairly simple to change the code itself, but there is
>> additional
>> >> >> >> work needed to implement the GUI change and update the
>> documentation.
>> >> >> >>
>> >> >> >> It's not yet clear if this is a general problem affecting multiple
>> >> >> >> servers, or just WordPress servers, or just an issue with the
>> >> >> >> particular WordPress host.
>> >> >> >>
>> >> >> >>> Or perhaps a sampler or postprocessor that allows you to
>> manipulate
>> >> >> explicit
>> >> >> >>> cookie values? That'd be a bit more work, but might be more
>> >> palatable.
>> >> >> >>
>> >> >> >> That can be done already with the Regex Processor and Header
>> Manager,
>> >> >> >> or using the BSH or BSF test elements.
>> >> >> >>
>> >> >> >> Might just be simpler to change the time on the box running JMeter
>> >> ...
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail:
>> jmeter-user-unsubscribe@jakarta.apache.org
>> >> >> >> For additional commands, e-mail:
>> jmeter-user-help@jakarta.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> >> > For additional commands, e-mail:
>> jmeter-user-help@jakarta.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
You are right , that is the problem . However im wondering what the right
behavior is
If I request "/testjmeter/wp-login.php"
Then arent these valid paths for set-cookie
/
/testjmeter
/testjmeter/wp-login.php
/testjmeter/child/  --> This is the problematic one. I was under the
impression this was allowed?

if my page is at the root /wp-login.php then I think all directories under /
are allowed in the Set-Cookie?

I tried to look through the cookie RFC and didnt seem to find information
one way or the other

I can verify your fix works
CookieManager.check.cookies=false -- Daniel this should work without needing
to manipulate cookies (In my example set this in jmeter.properties and
disable the pre processor that adds the cookie)



regards
deepak






On Thu, Jun 2, 2011 at 6:48 PM, sebb <se...@gmail.com> wrote:

> On 3 June 2011 02:32, Deepak Shetty <sh...@gmail.com> wrote:
> > Ok i will . Visually the cookies look fine and one of them does get sent
> in
> > the next request (the one without path and http only)
>
> When I try, I get several cookies rejected, e.g. with the message:
>
> (Illegal path attribute "/testjmeter/wp-admin". Path of origin:
> "/testjmeter/wp-login.php")
>
> Maybe that is part of the problem?
>
> > Daniel : see if
> >
> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
> > for you. I added the missing cookie programattically (various
> > hardcodes but you shoould be able to login - logout doesnt work because I
> > need to remove the cookie i set)
> >
> > regards
> > deepak
> >
> > On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
> >> > There seems to be a Jmeter Bug
> >> >
> >> > Login request gets the following as response
> >> >
> >> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
> >> > Set-Cookie:
> >> >
> >>
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> >> > path=/testjmeter/wp-content/plugins; httponly
> >> > *Set-Cookie:
> >> >
> >>
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> >> > path=/testjmeter/wp-admin; httponly
> >> > *Set-Cookie:
> >> >
> >>
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
> >> >
> >> > All good here
> >>
> >> Perhaps not - please enable Cookie Manager Debug logging to see if any
> >> of the cookies have been rejected, and why.
> >>
> >> > The next request
> >> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
> >> > Cookie Data:
> >> > wordpress_test_cookie=WP+Cookie+check;
> >> >
> >>
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
> >> >
> >> > doesnt have the cookie above  that I bolded which has an explicit path
> >> and
> >> > httponly (not sure which of the attributes cause a problem)
> >> >
> >> > Programatically setting the cookies seem to be the only workaround
> >> without
> >> > code fix, can you please confirm (I dont think expiry date has
> naything
> >> to
> >> > do with , like you say , past expiry is used to delete a cookie)
> >> > regards
> >> > deepak
> >> >
> >> >
> >> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
> >> >
> >> >> Yes; perhaps it is deliberately sending expired dates in order to
> >> >> delete the cookies. I have seen another server do this.
> >> >>
> >> >> From some biref experiments with your test site, I suspect the login
> >> >> problem is nothing to do with expired cookies after all, but there is
> >> >> probably some other setting that is not correct.
> >> >>
> >> >> Look for parameters that have odd-looking values; they may be being
> >> >> set by Javascript in the browser, in which case you will have to work
> >> >> out how to extract the relevant values from the previous reponse.
> >> >>
> >> >> Or record the login twice, and compare the generated test plans to
> see
> >> >> which entries have changed. You then have to work out how to extract
> >> >> the values they need. The Save Responses to a File Listener can be
> >> >> helpful here.
> >> >>
> >> >> BTW, JMeter cannot currently handle deflate encoding, so make sure
> you
> >> >> don't enable that in the Header Manager.
> >> >>
> >> >> Also, Excludes *do* work - make sure that there aren't any trailing
> >> >> spaces or other spurious characters in the fields.
> >> >>
> >> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com>
> wrote:
> >> >> > Did any of you notice that the Date of the request is accurate and
> so
> >> >> > are some of the cookies? WordPress seems to deliberately send the
> >> >> > login related cookies with the year old expiration. Others are
> fine.
> >> >> >
> >> >> > I mention this because there seems to be an idea that the server
> time
> >> >> > is configured wrong.
> >> >> >
> >> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
> >> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com>
> wrote:
> >> >> >>>  > I think it's a bit premature to suggest that WordPress is
> broken.
> >> It
> >> >> >>>  > is used on tens of millions of sites and people are able to
> login
> >> >> fine
> >> >> >>>  >every day.
> >> >> >>>
> >> >> >>> Number of users is not a quality metric! Look at Windows... (Heh
> heh
> >> >> heh)
> >> >> >>>
> >> >> >>>> Well there's your problem!
> >> >> >>>>
> >> >> >>>> That only affects the cookies that are stored in the cookies
> file
> >> >> >>>> (which is not normally used).
> >> >> >>>>
> >> >> >>>>
> >> >> >>> Doh! It seemed like such a likely culprit, too!
> >> >> >>>
> >> >> >>
> >> >> >> The actual expiry code is similar:
> >> >> >>
> >> >> >>                // Store session cookies as well as unexpired ones
> >> >> >>                if (exp == 0 || exp >= System.currentTimeMillis())
> {
> >> >> >>                    newCookie.setVersion(cookie.getVersion());
> >> >> >>                    add(newCookie); // Has its own debug log;
> removes
> >> >> >> matching cookies
> >> >> >>                } else {
> >> >> >>                    removeMatchingCookies(newCookie);
> >> >> >>                    if (debugEnabled){
> >> >> >>                        log.debug("Dropping expired Cookie:
> >> >> >> "+newCookie.toString());
> >> >> >>                    }
> >> >> >>                }
> >> >> >>
> >> >> >>
> >> >> >>>
> >> >> >>>> > I'd be really hesitant to change the behavior of the test
> >> >> environment to
> >> >> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a
> >> bug,
> >> >> and
> >> >> >>>> it's
> >> >> >>>> > something the guys running the server should fix.
> >> >> >>>>
> >> >> >>>> If this is a general problem, I suppose it might make sense to
> add
> >> an
> >> >> >>>> option to remove the expiry date from stale cookies, turning
> them
> >> into
> >> >> >>>> session cookies.
> >> >> >>>> But AFAIK this is the first time this has been reported [, and
> >> might
> >> >> >>>> cause indigestion (!) in some cases].
> >> >> >>>>
> >> >> >>>>
> >> >> >>> Well it sounds like the web browser is also storing and using the
> >> >> expired
> >> >> >>> cookie, and the remote server is honoring it! That's like 3
> >> different
> >> >> bugs
> >> >> >>> he's uncovered so far! At this point I'd be rampaging like...
> >> something
> >> >> that
> >> >> >>> rampages a LOT... through 2 or 3 different bug forums.
> >> >> >>>
> >> >> >>> I'm sure the Firefox guys would say "No it's not!" At least some
> >> people
> >> >> in
> >> >> >>> the "real world" do check cookie expiry dates, but it's probably
> >> >> "optional".
> >> >> >>> I'm not inclined to go digging through RFCs to find out.
> >> >> >>>
> >> >> >>> I'd say Wordpress sending out cookies from last year means
> someone
> >> >> hasn't
> >> >> >>> been minding a server like they should be. That really IS a
> problem.
> >> >> >>
> >> >> >> Agreed.
> >> >> >>
> >> >> >>> I suppose you could add a "Remove expiration dates" to the cookie
> >> >> manager
> >> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
> >> Probably
> >> >> >>> wouldn't be a huge amount of coding, and would probably be only
> >> vaguely
> >> >> >>> atrocious.
> >> >> >>
> >> >> >> It's fairly simple to change the code itself, but there is
> additional
> >> >> >> work needed to implement the GUI change and update the
> documentation.
> >> >> >>
> >> >> >> It's not yet clear if this is a general problem affecting multiple
> >> >> >> servers, or just WordPress servers, or just an issue with the
> >> >> >> particular WordPress host.
> >> >> >>
> >> >> >>> Or perhaps a sampler or postprocessor that allows you to
> manipulate
> >> >> explicit
> >> >> >>> cookie values? That'd be a bit more work, but might be more
> >> palatable.
> >> >> >>
> >> >> >> That can be done already with the Regex Processor and Header
> Manager,
> >> >> >> or using the BSH or BSF test elements.
> >> >> >>
> >> >> >> Might just be simpler to change the time on the box running JMeter
> >> ...
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> >> >> >> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> >> > For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 3 June 2011 02:32, Deepak Shetty <sh...@gmail.com> wrote:
> Ok i will . Visually the cookies look fine and one of them does get sent in
> the next request (the one without path and http only)

When I try, I get several cookies rejected, e.g. with the message:

(Illegal path attribute "/testjmeter/wp-admin". Path of origin:
"/testjmeter/wp-login.php")

Maybe that is part of the problem?

> Daniel : see if
> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
> for you. I added the missing cookie programattically (various
> hardcodes but you shoould be able to login - logout doesnt work because I
> need to remove the cookie i set)
>
> regards
> deepak
>
> On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:
>
>> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
>> > There seems to be a Jmeter Bug
>> >
>> > Login request gets the following as response
>> >
>> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
>> > Set-Cookie:
>> >
>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>> > path=/testjmeter/wp-content/plugins; httponly
>> > *Set-Cookie:
>> >
>> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
>> > path=/testjmeter/wp-admin; httponly
>> > *Set-Cookie:
>> >
>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
>> >
>> > All good here
>>
>> Perhaps not - please enable Cookie Manager Debug logging to see if any
>> of the cookies have been rejected, and why.
>>
>> > The next request
>> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
>> > Cookie Data:
>> > wordpress_test_cookie=WP+Cookie+check;
>> >
>> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
>> >
>> > doesnt have the cookie above  that I bolded which has an explicit path
>> and
>> > httponly (not sure which of the attributes cause a problem)
>> >
>> > Programatically setting the cookies seem to be the only workaround
>> without
>> > code fix, can you please confirm (I dont think expiry date has naything
>> to
>> > do with , like you say , past expiry is used to delete a cookie)
>> > regards
>> > deepak
>> >
>> >
>> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> Yes; perhaps it is deliberately sending expired dates in order to
>> >> delete the cookies. I have seen another server do this.
>> >>
>> >> From some biref experiments with your test site, I suspect the login
>> >> problem is nothing to do with expired cookies after all, but there is
>> >> probably some other setting that is not correct.
>> >>
>> >> Look for parameters that have odd-looking values; they may be being
>> >> set by Javascript in the browser, in which case you will have to work
>> >> out how to extract the relevant values from the previous reponse.
>> >>
>> >> Or record the login twice, and compare the generated test plans to see
>> >> which entries have changed. You then have to work out how to extract
>> >> the values they need. The Save Responses to a File Listener can be
>> >> helpful here.
>> >>
>> >> BTW, JMeter cannot currently handle deflate encoding, so make sure you
>> >> don't enable that in the Header Manager.
>> >>
>> >> Also, Excludes *do* work - make sure that there aren't any trailing
>> >> spaces or other spurious characters in the fields.
>> >>
>> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com> wrote:
>> >> > Did any of you notice that the Date of the request is accurate and so
>> >> > are some of the cookies? WordPress seems to deliberately send the
>> >> > login related cookies with the year old expiration. Others are fine.
>> >> >
>> >> > I mention this because there seems to be an idea that the server time
>> >> > is configured wrong.
>> >> >
>> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
>> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
>> >> >>>  > I think it's a bit premature to suggest that WordPress is broken.
>> It
>> >> >>>  > is used on tens of millions of sites and people are able to login
>> >> fine
>> >> >>>  >every day.
>> >> >>>
>> >> >>> Number of users is not a quality metric! Look at Windows... (Heh heh
>> >> heh)
>> >> >>>
>> >> >>>> Well there's your problem!
>> >> >>>>
>> >> >>>> That only affects the cookies that are stored in the cookies file
>> >> >>>> (which is not normally used).
>> >> >>>>
>> >> >>>>
>> >> >>> Doh! It seemed like such a likely culprit, too!
>> >> >>>
>> >> >>
>> >> >> The actual expiry code is similar:
>> >> >>
>> >> >>                // Store session cookies as well as unexpired ones
>> >> >>                if (exp == 0 || exp >= System.currentTimeMillis()) {
>> >> >>                    newCookie.setVersion(cookie.getVersion());
>> >> >>                    add(newCookie); // Has its own debug log; removes
>> >> >> matching cookies
>> >> >>                } else {
>> >> >>                    removeMatchingCookies(newCookie);
>> >> >>                    if (debugEnabled){
>> >> >>                        log.debug("Dropping expired Cookie:
>> >> >> "+newCookie.toString());
>> >> >>                    }
>> >> >>                }
>> >> >>
>> >> >>
>> >> >>>
>> >> >>>> > I'd be really hesitant to change the behavior of the test
>> >> environment to
>> >> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a
>> bug,
>> >> and
>> >> >>>> it's
>> >> >>>> > something the guys running the server should fix.
>> >> >>>>
>> >> >>>> If this is a general problem, I suppose it might make sense to add
>> an
>> >> >>>> option to remove the expiry date from stale cookies, turning them
>> into
>> >> >>>> session cookies.
>> >> >>>> But AFAIK this is the first time this has been reported [, and
>> might
>> >> >>>> cause indigestion (!) in some cases].
>> >> >>>>
>> >> >>>>
>> >> >>> Well it sounds like the web browser is also storing and using the
>> >> expired
>> >> >>> cookie, and the remote server is honoring it! That's like 3
>> different
>> >> bugs
>> >> >>> he's uncovered so far! At this point I'd be rampaging like...
>> something
>> >> that
>> >> >>> rampages a LOT... through 2 or 3 different bug forums.
>> >> >>>
>> >> >>> I'm sure the Firefox guys would say "No it's not!" At least some
>> people
>> >> in
>> >> >>> the "real world" do check cookie expiry dates, but it's probably
>> >> "optional".
>> >> >>> I'm not inclined to go digging through RFCs to find out.
>> >> >>>
>> >> >>> I'd say Wordpress sending out cookies from last year means someone
>> >> hasn't
>> >> >>> been minding a server like they should be. That really IS a problem.
>> >> >>
>> >> >> Agreed.
>> >> >>
>> >> >>> I suppose you could add a "Remove expiration dates" to the cookie
>> >> manager
>> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
>> Probably
>> >> >>> wouldn't be a huge amount of coding, and would probably be only
>> vaguely
>> >> >>> atrocious.
>> >> >>
>> >> >> It's fairly simple to change the code itself, but there is additional
>> >> >> work needed to implement the GUI change and update the documentation.
>> >> >>
>> >> >> It's not yet clear if this is a general problem affecting multiple
>> >> >> servers, or just WordPress servers, or just an issue with the
>> >> >> particular WordPress host.
>> >> >>
>> >> >>> Or perhaps a sampler or postprocessor that allows you to manipulate
>> >> explicit
>> >> >>> cookie values? That'd be a bit more work, but might be more
>> palatable.
>> >> >>
>> >> >> That can be done already with the Regex Processor and Header Manager,
>> >> >> or using the BSH or BSF test elements.
>> >> >>
>> >> >> Might just be simpler to change the time on the box running JMeter
>> ...
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
Ok i will . Visually the cookies look fine and one of them does get sent in
the next request (the one without path and http only)
Daniel : see if
http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks
for you. I added the missing cookie programattically (various
hardcodes but you shoould be able to login - logout doesnt work because I
need to remove the cookie i set)

regards
deepak

On Thu, Jun 2, 2011 at 6:18 PM, sebb <se...@gmail.com> wrote:

> On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
> > There seems to be a Jmeter Bug
> >
> > Login request gets the following as response
> >
> > Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
> > Set-Cookie:
> >
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> > path=/testjmeter/wp-content/plugins; httponly
> > *Set-Cookie:
> >
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> > path=/testjmeter/wp-admin; httponly
> > *Set-Cookie:
> >
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
> >
> > All good here
>
> Perhaps not - please enable Cookie Manager Debug logging to see if any
> of the cookies have been rejected, and why.
>
> > The next request
> > GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
> > Cookie Data:
> > wordpress_test_cookie=WP+Cookie+check;
> >
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
> >
> > doesnt have the cookie above  that I bolded which has an explicit path
> and
> > httponly (not sure which of the attributes cause a problem)
> >
> > Programatically setting the cookies seem to be the only workaround
> without
> > code fix, can you please confirm (I dont think expiry date has naything
> to
> > do with , like you say , past expiry is used to delete a cookie)
> > regards
> > deepak
> >
> >
> > On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
> >
> >> Yes; perhaps it is deliberately sending expired dates in order to
> >> delete the cookies. I have seen another server do this.
> >>
> >> From some biref experiments with your test site, I suspect the login
> >> problem is nothing to do with expired cookies after all, but there is
> >> probably some other setting that is not correct.
> >>
> >> Look for parameters that have odd-looking values; they may be being
> >> set by Javascript in the browser, in which case you will have to work
> >> out how to extract the relevant values from the previous reponse.
> >>
> >> Or record the login twice, and compare the generated test plans to see
> >> which entries have changed. You then have to work out how to extract
> >> the values they need. The Save Responses to a File Listener can be
> >> helpful here.
> >>
> >> BTW, JMeter cannot currently handle deflate encoding, so make sure you
> >> don't enable that in the Header Manager.
> >>
> >> Also, Excludes *do* work - make sure that there aren't any trailing
> >> spaces or other spurious characters in the fields.
> >>
> >> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com> wrote:
> >> > Did any of you notice that the Date of the request is accurate and so
> >> > are some of the cookies? WordPress seems to deliberately send the
> >> > login related cookies with the year old expiration. Others are fine.
> >> >
> >> > I mention this because there seems to be an idea that the server time
> >> > is configured wrong.
> >> >
> >> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
> >> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
> >> >>>  > I think it's a bit premature to suggest that WordPress is broken.
> It
> >> >>>  > is used on tens of millions of sites and people are able to login
> >> fine
> >> >>>  >every day.
> >> >>>
> >> >>> Number of users is not a quality metric! Look at Windows... (Heh heh
> >> heh)
> >> >>>
> >> >>>> Well there's your problem!
> >> >>>>
> >> >>>> That only affects the cookies that are stored in the cookies file
> >> >>>> (which is not normally used).
> >> >>>>
> >> >>>>
> >> >>> Doh! It seemed like such a likely culprit, too!
> >> >>>
> >> >>
> >> >> The actual expiry code is similar:
> >> >>
> >> >>                // Store session cookies as well as unexpired ones
> >> >>                if (exp == 0 || exp >= System.currentTimeMillis()) {
> >> >>                    newCookie.setVersion(cookie.getVersion());
> >> >>                    add(newCookie); // Has its own debug log; removes
> >> >> matching cookies
> >> >>                } else {
> >> >>                    removeMatchingCookies(newCookie);
> >> >>                    if (debugEnabled){
> >> >>                        log.debug("Dropping expired Cookie:
> >> >> "+newCookie.toString());
> >> >>                    }
> >> >>                }
> >> >>
> >> >>
> >> >>>
> >> >>>> > I'd be really hesitant to change the behavior of the test
> >> environment to
> >> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a
> bug,
> >> and
> >> >>>> it's
> >> >>>> > something the guys running the server should fix.
> >> >>>>
> >> >>>> If this is a general problem, I suppose it might make sense to add
> an
> >> >>>> option to remove the expiry date from stale cookies, turning them
> into
> >> >>>> session cookies.
> >> >>>> But AFAIK this is the first time this has been reported [, and
> might
> >> >>>> cause indigestion (!) in some cases].
> >> >>>>
> >> >>>>
> >> >>> Well it sounds like the web browser is also storing and using the
> >> expired
> >> >>> cookie, and the remote server is honoring it! That's like 3
> different
> >> bugs
> >> >>> he's uncovered so far! At this point I'd be rampaging like...
> something
> >> that
> >> >>> rampages a LOT... through 2 or 3 different bug forums.
> >> >>>
> >> >>> I'm sure the Firefox guys would say "No it's not!" At least some
> people
> >> in
> >> >>> the "real world" do check cookie expiry dates, but it's probably
> >> "optional".
> >> >>> I'm not inclined to go digging through RFCs to find out.
> >> >>>
> >> >>> I'd say Wordpress sending out cookies from last year means someone
> >> hasn't
> >> >>> been minding a server like they should be. That really IS a problem.
> >> >>
> >> >> Agreed.
> >> >>
> >> >>> I suppose you could add a "Remove expiration dates" to the cookie
> >> manager
> >> >>> panel, or a "send expired cookies" checkbox to the httpclient.
> Probably
> >> >>> wouldn't be a huge amount of coding, and would probably be only
> vaguely
> >> >>> atrocious.
> >> >>
> >> >> It's fairly simple to change the code itself, but there is additional
> >> >> work needed to implement the GUI change and update the documentation.
> >> >>
> >> >> It's not yet clear if this is a general problem affecting multiple
> >> >> servers, or just WordPress servers, or just an issue with the
> >> >> particular WordPress host.
> >> >>
> >> >>> Or perhaps a sampler or postprocessor that allows you to manipulate
> >> explicit
> >> >>> cookie values? That'd be a bit more work, but might be more
> palatable.
> >> >>
> >> >> That can be done already with the Regex Processor and Header Manager,
> >> >> or using the BSH or BSF test elements.
> >> >>
> >> >> Might just be simpler to change the time on the box running JMeter
> ...
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 3 June 2011 02:10, Deepak Shetty <sh...@gmail.com> wrote:
> There seems to be a Jmeter Bug
>
> Login request gets the following as response
>
> Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
> Set-Cookie:
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> path=/testjmeter/wp-content/plugins; httponly
> *Set-Cookie:
> wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
> path=/testjmeter/wp-admin; httponly
> *Set-Cookie:
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;
>
> All good here

Perhaps not - please enable Cookie Manager Debug logging to see if any
of the cookies have been rejected, and why.

> The next request
> GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
> Cookie Data:
> wordpress_test_cookie=WP+Cookie+check;
> wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1
>
> doesnt have the cookie above  that I bolded which has an explicit path and
> httponly (not sure which of the attributes cause a problem)
>
> Programatically setting the cookies seem to be the only workaround without
> code fix, can you please confirm (I dont think expiry date has naything to
> do with , like you say , past expiry is used to delete a cookie)
> regards
> deepak
>
>
> On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:
>
>> Yes; perhaps it is deliberately sending expired dates in order to
>> delete the cookies. I have seen another server do this.
>>
>> From some biref experiments with your test site, I suspect the login
>> problem is nothing to do with expired cookies after all, but there is
>> probably some other setting that is not correct.
>>
>> Look for parameters that have odd-looking values; they may be being
>> set by Javascript in the browser, in which case you will have to work
>> out how to extract the relevant values from the previous reponse.
>>
>> Or record the login twice, and compare the generated test plans to see
>> which entries have changed. You then have to work out how to extract
>> the values they need. The Save Responses to a File Listener can be
>> helpful here.
>>
>> BTW, JMeter cannot currently handle deflate encoding, so make sure you
>> don't enable that in the Header Manager.
>>
>> Also, Excludes *do* work - make sure that there aren't any trailing
>> spaces or other spurious characters in the fields.
>>
>> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com> wrote:
>> > Did any of you notice that the Date of the request is accurate and so
>> > are some of the cookies? WordPress seems to deliberately send the
>> > login related cookies with the year old expiration. Others are fine.
>> >
>> > I mention this because there seems to be an idea that the server time
>> > is configured wrong.
>> >
>> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
>> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
>> >>>  > I think it's a bit premature to suggest that WordPress is broken. It
>> >>>  > is used on tens of millions of sites and people are able to login
>> fine
>> >>>  >every day.
>> >>>
>> >>> Number of users is not a quality metric! Look at Windows... (Heh heh
>> heh)
>> >>>
>> >>>> Well there's your problem!
>> >>>>
>> >>>> That only affects the cookies that are stored in the cookies file
>> >>>> (which is not normally used).
>> >>>>
>> >>>>
>> >>> Doh! It seemed like such a likely culprit, too!
>> >>>
>> >>
>> >> The actual expiry code is similar:
>> >>
>> >>                // Store session cookies as well as unexpired ones
>> >>                if (exp == 0 || exp >= System.currentTimeMillis()) {
>> >>                    newCookie.setVersion(cookie.getVersion());
>> >>                    add(newCookie); // Has its own debug log; removes
>> >> matching cookies
>> >>                } else {
>> >>                    removeMatchingCookies(newCookie);
>> >>                    if (debugEnabled){
>> >>                        log.debug("Dropping expired Cookie:
>> >> "+newCookie.toString());
>> >>                    }
>> >>                }
>> >>
>> >>
>> >>>
>> >>>> > I'd be really hesitant to change the behavior of the test
>> environment to
>> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a bug,
>> and
>> >>>> it's
>> >>>> > something the guys running the server should fix.
>> >>>>
>> >>>> If this is a general problem, I suppose it might make sense to add an
>> >>>> option to remove the expiry date from stale cookies, turning them into
>> >>>> session cookies.
>> >>>> But AFAIK this is the first time this has been reported [, and might
>> >>>> cause indigestion (!) in some cases].
>> >>>>
>> >>>>
>> >>> Well it sounds like the web browser is also storing and using the
>> expired
>> >>> cookie, and the remote server is honoring it! That's like 3 different
>> bugs
>> >>> he's uncovered so far! At this point I'd be rampaging like... something
>> that
>> >>> rampages a LOT... through 2 or 3 different bug forums.
>> >>>
>> >>> I'm sure the Firefox guys would say "No it's not!" At least some people
>> in
>> >>> the "real world" do check cookie expiry dates, but it's probably
>> "optional".
>> >>> I'm not inclined to go digging through RFCs to find out.
>> >>>
>> >>> I'd say Wordpress sending out cookies from last year means someone
>> hasn't
>> >>> been minding a server like they should be. That really IS a problem.
>> >>
>> >> Agreed.
>> >>
>> >>> I suppose you could add a "Remove expiration dates" to the cookie
>> manager
>> >>> panel, or a "send expired cookies" checkbox to the httpclient. Probably
>> >>> wouldn't be a huge amount of coding, and would probably be only vaguely
>> >>> atrocious.
>> >>
>> >> It's fairly simple to change the code itself, but there is additional
>> >> work needed to implement the GUI change and update the documentation.
>> >>
>> >> It's not yet clear if this is a general problem affecting multiple
>> >> servers, or just WordPress servers, or just an issue with the
>> >> particular WordPress host.
>> >>
>> >>> Or perhaps a sampler or postprocessor that allows you to manipulate
>> explicit
>> >>> cookie values? That'd be a bit more work, but might be more palatable.
>> >>
>> >> That can be done already with the Regex Processor and Header Manager,
>> >> or using the BSH or BSF test elements.
>> >>
>> >> Might just be simpler to change the time on the box running JMeter ...
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
There seems to be a Jmeter Bug

Login request gets the following as response

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
Set-Cookie:
wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
path=/testjmeter/wp-content/plugins; httponly
*Set-Cookie:
wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1;
path=/testjmeter/wp-admin; httponly
*Set-Cookie:
wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1;

All good here
The next request
GET http://authnet.danielwatrous.com/testjmeter/wp-admin/
Cookie Data:
wordpress_test_cookie=WP+Cookie+check;
wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1

doesnt have the cookie above  that I bolded which has an explicit path and
httponly (not sure which of the attributes cause a problem)

Programatically setting the cookies seem to be the only workaround without
code fix, can you please confirm (I dont think expiry date has naything to
do with , like you say , past expiry is used to delete a cookie)
regards
deepak


On Thu, Jun 2, 2011 at 5:52 PM, sebb <se...@gmail.com> wrote:

> Yes; perhaps it is deliberately sending expired dates in order to
> delete the cookies. I have seen another server do this.
>
> From some biref experiments with your test site, I suspect the login
> problem is nothing to do with expired cookies after all, but there is
> probably some other setting that is not correct.
>
> Look for parameters that have odd-looking values; they may be being
> set by Javascript in the browser, in which case you will have to work
> out how to extract the relevant values from the previous reponse.
>
> Or record the login twice, and compare the generated test plans to see
> which entries have changed. You then have to work out how to extract
> the values they need. The Save Responses to a File Listener can be
> helpful here.
>
> BTW, JMeter cannot currently handle deflate encoding, so make sure you
> don't enable that in the Header Manager.
>
> Also, Excludes *do* work - make sure that there aren't any trailing
> spaces or other spurious characters in the fields.
>
> On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com> wrote:
> > Did any of you notice that the Date of the request is accurate and so
> > are some of the cookies? WordPress seems to deliberately send the
> > login related cookies with the year old expiration. Others are fine.
> >
> > I mention this because there seems to be an idea that the server time
> > is configured wrong.
> >
> > On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
> >> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
> >>>  > I think it's a bit premature to suggest that WordPress is broken. It
> >>>  > is used on tens of millions of sites and people are able to login
> fine
> >>>  >every day.
> >>>
> >>> Number of users is not a quality metric! Look at Windows... (Heh heh
> heh)
> >>>
> >>>> Well there's your problem!
> >>>>
> >>>> That only affects the cookies that are stored in the cookies file
> >>>> (which is not normally used).
> >>>>
> >>>>
> >>> Doh! It seemed like such a likely culprit, too!
> >>>
> >>
> >> The actual expiry code is similar:
> >>
> >>                // Store session cookies as well as unexpired ones
> >>                if (exp == 0 || exp >= System.currentTimeMillis()) {
> >>                    newCookie.setVersion(cookie.getVersion());
> >>                    add(newCookie); // Has its own debug log; removes
> >> matching cookies
> >>                } else {
> >>                    removeMatchingCookies(newCookie);
> >>                    if (debugEnabled){
> >>                        log.debug("Dropping expired Cookie:
> >> "+newCookie.toString());
> >>                    }
> >>                }
> >>
> >>
> >>>
> >>>> > I'd be really hesitant to change the behavior of the test
> environment to
> >>>> > mask a bug you uncovered, though. Sending expired cookies IS a bug,
> and
> >>>> it's
> >>>> > something the guys running the server should fix.
> >>>>
> >>>> If this is a general problem, I suppose it might make sense to add an
> >>>> option to remove the expiry date from stale cookies, turning them into
> >>>> session cookies.
> >>>> But AFAIK this is the first time this has been reported [, and might
> >>>> cause indigestion (!) in some cases].
> >>>>
> >>>>
> >>> Well it sounds like the web browser is also storing and using the
> expired
> >>> cookie, and the remote server is honoring it! That's like 3 different
> bugs
> >>> he's uncovered so far! At this point I'd be rampaging like... something
> that
> >>> rampages a LOT... through 2 or 3 different bug forums.
> >>>
> >>> I'm sure the Firefox guys would say "No it's not!" At least some people
> in
> >>> the "real world" do check cookie expiry dates, but it's probably
> "optional".
> >>> I'm not inclined to go digging through RFCs to find out.
> >>>
> >>> I'd say Wordpress sending out cookies from last year means someone
> hasn't
> >>> been minding a server like they should be. That really IS a problem.
> >>
> >> Agreed.
> >>
> >>> I suppose you could add a "Remove expiration dates" to the cookie
> manager
> >>> panel, or a "send expired cookies" checkbox to the httpclient. Probably
> >>> wouldn't be a huge amount of coding, and would probably be only vaguely
> >>> atrocious.
> >>
> >> It's fairly simple to change the code itself, but there is additional
> >> work needed to implement the GUI change and update the documentation.
> >>
> >> It's not yet clear if this is a general problem affecting multiple
> >> servers, or just WordPress servers, or just an issue with the
> >> particular WordPress host.
> >>
> >>> Or perhaps a sampler or postprocessor that allows you to manipulate
> explicit
> >>> cookie values? That'd be a bit more work, but might be more palatable.
> >>
> >> That can be done already with the Regex Processor and Header Manager,
> >> or using the BSH or BSF test elements.
> >>
> >> Might just be simpler to change the time on the box running JMeter ...
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
Yes; perhaps it is deliberately sending expired dates in order to
delete the cookies. I have seen another server do this.

>From some biref experiments with your test site, I suspect the login
problem is nothing to do with expired cookies after all, but there is
probably some other setting that is not correct.

Look for parameters that have odd-looking values; they may be being
set by Javascript in the browser, in which case you will have to work
out how to extract the relevant values from the previous reponse.

Or record the login twice, and compare the generated test plans to see
which entries have changed. You then have to work out how to extract
the values they need. The Save Responses to a File Listener can be
helpful here.

BTW, JMeter cannot currently handle deflate encoding, so make sure you
don't enable that in the Header Manager.

Also, Excludes *do* work - make sure that there aren't any trailing
spaces or other spurious characters in the fields.

On 3 June 2011 01:30, Daniel Watrous <da...@gmail.com> wrote:
> Did any of you notice that the Date of the request is accurate and so
> are some of the cookies? WordPress seems to deliberately send the
> login related cookies with the year old expiration. Others are fine.
>
> I mention this because there seems to be an idea that the server time
> is configured wrong.
>
> On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
>> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
>>>  > I think it's a bit premature to suggest that WordPress is broken. It
>>>  > is used on tens of millions of sites and people are able to login fine
>>>  >every day.
>>>
>>> Number of users is not a quality metric! Look at Windows... (Heh heh heh)
>>>
>>>> Well there's your problem!
>>>>
>>>> That only affects the cookies that are stored in the cookies file
>>>> (which is not normally used).
>>>>
>>>>
>>> Doh! It seemed like such a likely culprit, too!
>>>
>>
>> The actual expiry code is similar:
>>
>>                // Store session cookies as well as unexpired ones
>>                if (exp == 0 || exp >= System.currentTimeMillis()) {
>>                    newCookie.setVersion(cookie.getVersion());
>>                    add(newCookie); // Has its own debug log; removes
>> matching cookies
>>                } else {
>>                    removeMatchingCookies(newCookie);
>>                    if (debugEnabled){
>>                        log.debug("Dropping expired Cookie:
>> "+newCookie.toString());
>>                    }
>>                }
>>
>>
>>>
>>>> > I'd be really hesitant to change the behavior of the test environment to
>>>> > mask a bug you uncovered, though. Sending expired cookies IS a bug, and
>>>> it's
>>>> > something the guys running the server should fix.
>>>>
>>>> If this is a general problem, I suppose it might make sense to add an
>>>> option to remove the expiry date from stale cookies, turning them into
>>>> session cookies.
>>>> But AFAIK this is the first time this has been reported [, and might
>>>> cause indigestion (!) in some cases].
>>>>
>>>>
>>> Well it sounds like the web browser is also storing and using the expired
>>> cookie, and the remote server is honoring it! That's like 3 different bugs
>>> he's uncovered so far! At this point I'd be rampaging like... something that
>>> rampages a LOT... through 2 or 3 different bug forums.
>>>
>>> I'm sure the Firefox guys would say "No it's not!" At least some people in
>>> the "real world" do check cookie expiry dates, but it's probably "optional".
>>> I'm not inclined to go digging through RFCs to find out.
>>>
>>> I'd say Wordpress sending out cookies from last year means someone hasn't
>>> been minding a server like they should be. That really IS a problem.
>>
>> Agreed.
>>
>>> I suppose you could add a "Remove expiration dates" to the cookie manager
>>> panel, or a "send expired cookies" checkbox to the httpclient. Probably
>>> wouldn't be a huge amount of coding, and would probably be only vaguely
>>> atrocious.
>>
>> It's fairly simple to change the code itself, but there is additional
>> work needed to implement the GUI change and update the documentation.
>>
>> It's not yet clear if this is a general problem affecting multiple
>> servers, or just WordPress servers, or just an issue with the
>> particular WordPress host.
>>
>>> Or perhaps a sampler or postprocessor that allows you to manipulate explicit
>>> cookie values? That'd be a bit more work, but might be more palatable.
>>
>> That can be done already with the Regex Processor and Header Manager,
>> or using the BSH or BSF test elements.
>>
>> Might just be simpler to change the time on the box running JMeter ...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Deepak Shetty <sh...@gmail.com>.
Hi
where are you seeing the invalid cookies(sorry havent seen your screencast).
i tried with firefox to login
I get

*http://authnet.danielwatrous.com/testjmeter/wp-login.php*

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
Set-Cookie:
wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307234422%7Cc8c4e5bb5f9bacc38cf0d3f6a5a19125;
path=/testjmeter/wp-content/plugins; httponly
Set-Cookie:
wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307234422%7Cc8c4e5bb5f9bacc38cf0d3f6a5a19125;
path=/testjmeter/wp-admin; httponly
Set-Cookie:
wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307234422%7C0499d7fe3fd97c79cefda4d96eb98156;
path=/testjmeter/; httponly

*http://authnet.danielwatrous.com/testjmeter/wp-admin/*

Set-Cookie:
wp-settings-1=m8%3Dc%26m6%3Dc%26m10%3Dc%26m11%3Do%26m7%3Do%26m4%3Dc%26m12%3Dc%26m0%3Dc%26m1%3Dc;
expires=Sat, 02-Jun-2012 00:40:23 GMT; path=/testjmeter/
Set-Cookie: wp-settings-time-1=1307061623; expires=Sat, 02-Jun-2012 00:40:23
GMT; path=/testjmeter/

Atleast the browser behaves correctly - as far as I remember setting the
expiry date to the past is equivalent to deleting the cookie - so if you set
expiry in the past , then the browser wont send the cookie either

regards
deepak


On Thu, Jun 2, 2011 at 5:30 PM, Daniel Watrous <da...@gmail.com>wrote:

> Did any of you notice that the Date of the request is accurate and so
> are some of the cookies? WordPress seems to deliberately send the
> login related cookies with the year old expiration. Others are fine.
>
> I mention this because there seems to be an idea that the server time
> is configured wrong.
>
> On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
> > On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
> >>  > I think it's a bit premature to suggest that WordPress is broken. It
> >>  > is used on tens of millions of sites and people are able to login
> fine
> >>  >every day.
> >>
> >> Number of users is not a quality metric! Look at Windows... (Heh heh
> heh)
> >>
> >>> Well there's your problem!
> >>>
> >>> That only affects the cookies that are stored in the cookies file
> >>> (which is not normally used).
> >>>
> >>>
> >> Doh! It seemed like such a likely culprit, too!
> >>
> >
> > The actual expiry code is similar:
> >
> >                // Store session cookies as well as unexpired ones
> >                if (exp == 0 || exp >= System.currentTimeMillis()) {
> >                    newCookie.setVersion(cookie.getVersion());
> >                    add(newCookie); // Has its own debug log; removes
> > matching cookies
> >                } else {
> >                    removeMatchingCookies(newCookie);
> >                    if (debugEnabled){
> >                        log.debug("Dropping expired Cookie:
> > "+newCookie.toString());
> >                    }
> >                }
> >
> >
> >>
> >>> > I'd be really hesitant to change the behavior of the test environment
> to
> >>> > mask a bug you uncovered, though. Sending expired cookies IS a bug,
> and
> >>> it's
> >>> > something the guys running the server should fix.
> >>>
> >>> If this is a general problem, I suppose it might make sense to add an
> >>> option to remove the expiry date from stale cookies, turning them into
> >>> session cookies.
> >>> But AFAIK this is the first time this has been reported [, and might
> >>> cause indigestion (!) in some cases].
> >>>
> >>>
> >> Well it sounds like the web browser is also storing and using the
> expired
> >> cookie, and the remote server is honoring it! That's like 3 different
> bugs
> >> he's uncovered so far! At this point I'd be rampaging like... something
> that
> >> rampages a LOT... through 2 or 3 different bug forums.
> >>
> >> I'm sure the Firefox guys would say "No it's not!" At least some people
> in
> >> the "real world" do check cookie expiry dates, but it's probably
> "optional".
> >> I'm not inclined to go digging through RFCs to find out.
> >>
> >> I'd say Wordpress sending out cookies from last year means someone
> hasn't
> >> been minding a server like they should be. That really IS a problem.
> >
> > Agreed.
> >
> >> I suppose you could add a "Remove expiration dates" to the cookie
> manager
> >> panel, or a "send expired cookies" checkbox to the httpclient. Probably
> >> wouldn't be a huge amount of coding, and would probably be only vaguely
> >> atrocious.
> >
> > It's fairly simple to change the code itself, but there is additional
> > work needed to implement the GUI change and update the documentation.
> >
> > It's not yet clear if this is a general problem affecting multiple
> > servers, or just WordPress servers, or just an issue with the
> > particular WordPress host.
> >
> >> Or perhaps a sampler or postprocessor that allows you to manipulate
> explicit
> >> cookie values? That'd be a bit more work, but might be more palatable.
> >
> > That can be done already with the Regex Processor and Header Manager,
> > or using the BSH or BSF test elements.
> >
> > Might just be simpler to change the time on the box running JMeter ...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: cookie manager not working

Posted by Daniel Watrous <da...@gmail.com>.
Did any of you notice that the Date of the request is accurate and so
are some of the cookies? WordPress seems to deliberately send the
login related cookies with the year old expiration. Others are fine.

I mention this because there seems to be an idea that the server time
is configured wrong.

On Thu, Jun 2, 2011 at 4:32 PM, sebb <se...@gmail.com> wrote:
> On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
>>  > I think it's a bit premature to suggest that WordPress is broken. It
>>  > is used on tens of millions of sites and people are able to login fine
>>  >every day.
>>
>> Number of users is not a quality metric! Look at Windows... (Heh heh heh)
>>
>>> Well there's your problem!
>>>
>>> That only affects the cookies that are stored in the cookies file
>>> (which is not normally used).
>>>
>>>
>> Doh! It seemed like such a likely culprit, too!
>>
>
> The actual expiry code is similar:
>
>                // Store session cookies as well as unexpired ones
>                if (exp == 0 || exp >= System.currentTimeMillis()) {
>                    newCookie.setVersion(cookie.getVersion());
>                    add(newCookie); // Has its own debug log; removes
> matching cookies
>                } else {
>                    removeMatchingCookies(newCookie);
>                    if (debugEnabled){
>                        log.debug("Dropping expired Cookie:
> "+newCookie.toString());
>                    }
>                }
>
>
>>
>>> > I'd be really hesitant to change the behavior of the test environment to
>>> > mask a bug you uncovered, though. Sending expired cookies IS a bug, and
>>> it's
>>> > something the guys running the server should fix.
>>>
>>> If this is a general problem, I suppose it might make sense to add an
>>> option to remove the expiry date from stale cookies, turning them into
>>> session cookies.
>>> But AFAIK this is the first time this has been reported [, and might
>>> cause indigestion (!) in some cases].
>>>
>>>
>> Well it sounds like the web browser is also storing and using the expired
>> cookie, and the remote server is honoring it! That's like 3 different bugs
>> he's uncovered so far! At this point I'd be rampaging like... something that
>> rampages a LOT... through 2 or 3 different bug forums.
>>
>> I'm sure the Firefox guys would say "No it's not!" At least some people in
>> the "real world" do check cookie expiry dates, but it's probably "optional".
>> I'm not inclined to go digging through RFCs to find out.
>>
>> I'd say Wordpress sending out cookies from last year means someone hasn't
>> been minding a server like they should be. That really IS a problem.
>
> Agreed.
>
>> I suppose you could add a "Remove expiration dates" to the cookie manager
>> panel, or a "send expired cookies" checkbox to the httpclient. Probably
>> wouldn't be a huge amount of coding, and would probably be only vaguely
>> atrocious.
>
> It's fairly simple to change the code itself, but there is additional
> work needed to implement the GUI change and update the documentation.
>
> It's not yet clear if this is a general problem affecting multiple
> servers, or just WordPress servers, or just an issue with the
> particular WordPress host.
>
>> Or perhaps a sampler or postprocessor that allows you to manipulate explicit
>> cookie values? That'd be a bit more work, but might be more palatable.
>
> That can be done already with the Regex Processor and Header Manager,
> or using the BSH or BSF test elements.
>
> Might just be simpler to change the time on the box running JMeter ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 2 June 2011 17:26, Bruce Ide <fl...@gmail.com> wrote:
>  > I think it's a bit premature to suggest that WordPress is broken. It
>  > is used on tens of millions of sites and people are able to login fine
>  >every day.
>
> Number of users is not a quality metric! Look at Windows... (Heh heh heh)
>
>> Well there's your problem!
>>
>> That only affects the cookies that are stored in the cookies file
>> (which is not normally used).
>>
>>
> Doh! It seemed like such a likely culprit, too!
>

The actual expiry code is similar:

                // Store session cookies as well as unexpired ones
                if (exp == 0 || exp >= System.currentTimeMillis()) {
                    newCookie.setVersion(cookie.getVersion());
                    add(newCookie); // Has its own debug log; removes
matching cookies
                } else {
                    removeMatchingCookies(newCookie);
                    if (debugEnabled){
                        log.debug("Dropping expired Cookie:
"+newCookie.toString());
                    }
                }


>
>> > I'd be really hesitant to change the behavior of the test environment to
>> > mask a bug you uncovered, though. Sending expired cookies IS a bug, and
>> it's
>> > something the guys running the server should fix.
>>
>> If this is a general problem, I suppose it might make sense to add an
>> option to remove the expiry date from stale cookies, turning them into
>> session cookies.
>> But AFAIK this is the first time this has been reported [, and might
>> cause indigestion (!) in some cases].
>>
>>
> Well it sounds like the web browser is also storing and using the expired
> cookie, and the remote server is honoring it! That's like 3 different bugs
> he's uncovered so far! At this point I'd be rampaging like... something that
> rampages a LOT... through 2 or 3 different bug forums.
>
> I'm sure the Firefox guys would say "No it's not!" At least some people in
> the "real world" do check cookie expiry dates, but it's probably "optional".
> I'm not inclined to go digging through RFCs to find out.
>
> I'd say Wordpress sending out cookies from last year means someone hasn't
> been minding a server like they should be. That really IS a problem.

Agreed.

> I suppose you could add a "Remove expiration dates" to the cookie manager
> panel, or a "send expired cookies" checkbox to the httpclient. Probably
> wouldn't be a huge amount of coding, and would probably be only vaguely
> atrocious.

It's fairly simple to change the code itself, but there is additional
work needed to implement the GUI change and update the documentation.

It's not yet clear if this is a general problem affecting multiple
servers, or just WordPress servers, or just an issue with the
particular WordPress host.

> Or perhaps a sampler or postprocessor that allows you to manipulate explicit
> cookie values? That'd be a bit more work, but might be more palatable.

That can be done already with the Regex Processor and Header Manager,
or using the BSH or BSF test elements.

Might just be simpler to change the time on the box running JMeter ...

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Bruce Ide <fl...@gmail.com>.
 > I think it's a bit premature to suggest that WordPress is broken. It
 > is used on tens of millions of sites and people are able to login fine
 >every day.

Number of users is not a quality metric! Look at Windows... (Heh heh heh)

> Well there's your problem!
>
> That only affects the cookies that are stored in the cookies file
> (which is not normally used).
>
>
Doh! It seemed like such a likely culprit, too!


> > I'd be really hesitant to change the behavior of the test environment to
> > mask a bug you uncovered, though. Sending expired cookies IS a bug, and
> it's
> > something the guys running the server should fix.
>
> If this is a general problem, I suppose it might make sense to add an
> option to remove the expiry date from stale cookies, turning them into
> session cookies.
> But AFAIK this is the first time this has been reported [, and might
> cause indigestion (!) in some cases].
>
>
Well it sounds like the web browser is also storing and using the expired
cookie, and the remote server is honoring it! That's like 3 different bugs
he's uncovered so far! At this point I'd be rampaging like... something that
rampages a LOT... through 2 or 3 different bug forums.

I'm sure the Firefox guys would say "No it's not!" At least some people in
the "real world" do check cookie expiry dates, but it's probably "optional".
I'm not inclined to go digging through RFCs to find out.

I'd say Wordpress sending out cookies from last year means someone hasn't
been minding a server like they should be. That really IS a problem.

I suppose you could add a "Remove expiration dates" to the cookie manager
panel, or a "send expired cookies" checkbox to the httpclient. Probably
wouldn't be a huge amount of coding, and would probably be only vaguely
atrocious.

Or perhaps a sampler or postprocessor that allows you to manipulate explicit
cookie values? That'd be a bit more work, but might be more palatable.

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 2 June 2011 16:35, Bruce Ide <fl...@gmail.com> wrote:
> Jmeter's doing the right thing. If you're testing wordpress, file a bug with
> them and tell them to fix their thing. If you're running an application
> server yourself, I'd suspect it's something wrong with your application
> server config.

I'm inclined to agree - as far as I can tell, session cookies are
cookies without an expiry date or age.

> You have the jmeter source, you could always change its behavior to do what
> you want and recompile it. I'd start with CookieManager.java:
>
>        while (cookies.hasNext()) {
>            Cookie cook = (Cookie) cookies.next().getObjectValue();
>            final long expiresMillis = cook.getExpiresMillis();
>            if (expiresMillis == 0 || expiresMillis > now) { // only save
> unexpired cookies
>                writer.println(cookieToString(cook));
>            }
>        }
>
> Well there's your problem!

That only affects the cookies that are stored in the cookies file
(which is not normally used).

> I can't guarantee that's the only thing that
> prevents expired cookies from being sent. I suspect there's probably also
> some code in httpclient that checks to see if they're expired before sending
> them back.

Yes.
JMeter currently uses the Commons HttpClient 3.1 cookie handling code.

> I'd be really hesitant to change the behavior of the test environment to
> mask a bug you uncovered, though. Sending expired cookies IS a bug, and it's
> something the guys running the server should fix.

If this is a general problem, I suppose it might make sense to add an
option to remove the expiry date from stale cookies, turning them into
session cookies.
But AFAIK this is the first time this has been reported [, and might
cause indigestion (!) in some cases].

Note that cookies won't be handled properly if you have selected
"redirect automatically", because then JMeter does not see the cookies

> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Bruce Ide <fl...@gmail.com>.
Jmeter's doing the right thing. If you're testing wordpress, file a bug with
them and tell them to fix their thing. If you're running an application
server yourself, I'd suspect it's something wrong with your application
server config.

You have the jmeter source, you could always change its behavior to do what
you want and recompile it. I'd start with CookieManager.java:

        while (cookies.hasNext()) {
            Cookie cook = (Cookie) cookies.next().getObjectValue();
            final long expiresMillis = cook.getExpiresMillis();
            if (expiresMillis == 0 || expiresMillis > now) { // only save
unexpired cookies
                writer.println(cookieToString(cook));
            }
        }

Well there's your problem! I can't guarantee that's the only thing that
prevents expired cookies from being sent. I suspect there's probably also
some code in httpclient that checks to see if they're expired before sending
them back.

I'd be really hesitant to change the behavior of the test environment to
mask a bug you uncovered, though. Sending expired cookies IS a bug, and it's
something the guys running the server should fix.

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: cookie manager not working

Posted by Daniel Watrous <da...@gmail.com>.
I'm still struggling with this. I've made the following video that
will hopefully give enough detail to help me along:
http://www.screencast.com/t/Dafijet8P9VS

I've also created a test site if that helps you troubleshoot this issue with me.
http://authnet.danielwatrous.com/testjmeter/
username: admin
password: test

The log file had to do with permissions. When I moved the jmeter files
outside of the program files folder it was able to create the log
file.

Thank you.

On Wed, Jun 1, 2011 at 7:40 PM, sebb <se...@gmail.com> wrote:
> On 2 June 2011 02:06, Daniel Watrous <da...@gmail.com> wrote:
>> I've discovered that the cookies sent back by wordpress have an
>> expires value one year before the date of the request. Browsers seem
>> to store this as a session cookie, but I'm not sure why. Is there some
>> way to tell the cookie manager to deal with these cookies that have an
>> expires value before right now?
>
> No, not without modifying JMeter code.
> However, by judicious use of the Regex Extractor you should be able to
> extract the cookie from the header and then add it using a Header
> Manager.
>
>> I've put in a post on the wordpress forum to figure out why they do it that way.
>>
>> I also can't find a log file. How can I troubleshoot the reason a log
>> file won't write?
>
> Check if the launch directory is writable. Are you sure there is no
> jmeter.log file?
>
>> Daniel
>>
>> On Fri, May 27, 2011 at 7:29 AM, sebb <se...@gmail.com> wrote:
>>> On 27 May 2011 14:17, Daniel Watrous <da...@gmail.com> wrote:
>>>> I had actually tried that before mailing to the list. I just tried it
>>>> again with no change to whether cookies are sent or not.
>>>
>>> In that case, you'll need to enable debug logging  for the Cookie
>>> Manager: select it and use the Menu item Help/Enable Debug
>>>
>>> Output will be in the log file.
>>>
>>>> I can't find the log file, but here's my java version:
>>>
>>> Unless you override the location in the jmeter.properties file, the
>>> log file will be in the directory where you started JMeter from, by
>>> default the bin directory, and will be called jmeter.log.
>>>
>>>> C:\Program Files (x86)\Console2>java -version
>>>> java version "1.6.0_20"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
>>>> Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
>>>>
>>>> C:\Program Files (x86)\Console2>
>>>>
>>>> Windows 7 x64
>>>>
>>>> thanks,
>>>>
>>>> Daniel
>>>>
>>>>
>>>>
>>>> On Fri, May 27, 2011 at 3:03 AM, sebb <se...@gmail.com> wrote:
>>>>> On 27 May 2011 08:48, sebb <se...@gmail.com> wrote:
>>>>>> On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've been trying to setup a jmeter program to test a wordpress plugin.
>>>>>>> However, I can't get the login to work. It appears to be sending the
>>>>>>> cookies back correctly when the login is sent, but they don't get
>>>>>>> picked up by the cookie manager.
>>>>>>>
>>>>>>> I've been searching for a while and looked at dozens of examples.
>>>>>>> Maybe you can spot what I've done wrong from these screenshots:
>>>>>>>
>>>>>>> http://screencast.com/t/EW1zAgvlK
>>>>>>> http://screencast.com/t/2i8dTyBh
>>>>>>> http://screencast.com/t/fd5dGPvCb
>>>>>>
>>>>>> The Cookie Manager is set to require RFC2109 cookies; these have a
>>>>>> specific format that is not always followed by servers (or browsers).
>>>>>>
>>>>>> The default is supposed to be "compatibility" mode, try using that.
>>>>>>
>>>>>> What version of Java are you using? This will be shown near the start
>>>>>> of the jmeter.log file, e.g.
>>>>>>
>>>>>> java.version=1.5.0_22
>>>>>> java.vm.name=Java HotSpot(TM) Client VM
>>>>>>
>>>>>> I've just noticed that the default when adding a new Cookie Manager is
>>>>>> set correctly to "compatibility" (first option) when using that
>>>>>
>>>>> Actually it's the last option when using Java 1.5, first when using
>>>>> 1.6 - which is where the problem lies ...
>>>>>
>>>>>> version, however when using
>>>>>>
>>>>>> java.version=1.6.0_25
>>>>>> java.vm.name=Java HotSpot(TM) Client VM
>>>>>>
>>>>>> which is the current Java version it is set to "rfc109" (the last option).
>>>>>>
>>>>>> This is odd, since the code specifically tries to set "compatibility" mode.
>>>>>> Looks like there may be a Java bug (or at least a change in behaviour).
>>>>>
>>>>> It's a change in Java behaviour - the order of cookie policies is
>>>>> different, because of internal changes to the libraries.
>>>>>
>>>>> JMeter incorrectly relies on the order of the entries. Oops.
>>>>>
>>>>> However, there's an easy work-round - just change the policy to compatibility.
>>>>>
>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Daniel
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 2 June 2011 02:06, Daniel Watrous <da...@gmail.com> wrote:
> I've discovered that the cookies sent back by wordpress have an
> expires value one year before the date of the request. Browsers seem
> to store this as a session cookie, but I'm not sure why. Is there some
> way to tell the cookie manager to deal with these cookies that have an
> expires value before right now?

No, not without modifying JMeter code.
However, by judicious use of the Regex Extractor you should be able to
extract the cookie from the header and then add it using a Header
Manager.

> I've put in a post on the wordpress forum to figure out why they do it that way.
>
> I also can't find a log file. How can I troubleshoot the reason a log
> file won't write?

Check if the launch directory is writable. Are you sure there is no
jmeter.log file?

> Daniel
>
> On Fri, May 27, 2011 at 7:29 AM, sebb <se...@gmail.com> wrote:
>> On 27 May 2011 14:17, Daniel Watrous <da...@gmail.com> wrote:
>>> I had actually tried that before mailing to the list. I just tried it
>>> again with no change to whether cookies are sent or not.
>>
>> In that case, you'll need to enable debug logging  for the Cookie
>> Manager: select it and use the Menu item Help/Enable Debug
>>
>> Output will be in the log file.
>>
>>> I can't find the log file, but here's my java version:
>>
>> Unless you override the location in the jmeter.properties file, the
>> log file will be in the directory where you started JMeter from, by
>> default the bin directory, and will be called jmeter.log.
>>
>>> C:\Program Files (x86)\Console2>java -version
>>> java version "1.6.0_20"
>>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
>>> Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
>>>
>>> C:\Program Files (x86)\Console2>
>>>
>>> Windows 7 x64
>>>
>>> thanks,
>>>
>>> Daniel
>>>
>>>
>>>
>>> On Fri, May 27, 2011 at 3:03 AM, sebb <se...@gmail.com> wrote:
>>>> On 27 May 2011 08:48, sebb <se...@gmail.com> wrote:
>>>>> On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I've been trying to setup a jmeter program to test a wordpress plugin.
>>>>>> However, I can't get the login to work. It appears to be sending the
>>>>>> cookies back correctly when the login is sent, but they don't get
>>>>>> picked up by the cookie manager.
>>>>>>
>>>>>> I've been searching for a while and looked at dozens of examples.
>>>>>> Maybe you can spot what I've done wrong from these screenshots:
>>>>>>
>>>>>> http://screencast.com/t/EW1zAgvlK
>>>>>> http://screencast.com/t/2i8dTyBh
>>>>>> http://screencast.com/t/fd5dGPvCb
>>>>>
>>>>> The Cookie Manager is set to require RFC2109 cookies; these have a
>>>>> specific format that is not always followed by servers (or browsers).
>>>>>
>>>>> The default is supposed to be "compatibility" mode, try using that.
>>>>>
>>>>> What version of Java are you using? This will be shown near the start
>>>>> of the jmeter.log file, e.g.
>>>>>
>>>>> java.version=1.5.0_22
>>>>> java.vm.name=Java HotSpot(TM) Client VM
>>>>>
>>>>> I've just noticed that the default when adding a new Cookie Manager is
>>>>> set correctly to "compatibility" (first option) when using that
>>>>
>>>> Actually it's the last option when using Java 1.5, first when using
>>>> 1.6 - which is where the problem lies ...
>>>>
>>>>> version, however when using
>>>>>
>>>>> java.version=1.6.0_25
>>>>> java.vm.name=Java HotSpot(TM) Client VM
>>>>>
>>>>> which is the current Java version it is set to "rfc109" (the last option).
>>>>>
>>>>> This is odd, since the code specifically tries to set "compatibility" mode.
>>>>> Looks like there may be a Java bug (or at least a change in behaviour).
>>>>
>>>> It's a change in Java behaviour - the order of cookie policies is
>>>> different, because of internal changes to the libraries.
>>>>
>>>> JMeter incorrectly relies on the order of the entries. Oops.
>>>>
>>>> However, there's an easy work-round - just change the policy to compatibility.
>>>>
>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Daniel Watrous <da...@gmail.com>.
I've discovered that the cookies sent back by wordpress have an
expires value one year before the date of the request. Browsers seem
to store this as a session cookie, but I'm not sure why. Is there some
way to tell the cookie manager to deal with these cookies that have an
expires value before right now?

I've put in a post on the wordpress forum to figure out why they do it that way.

I also can't find a log file. How can I troubleshoot the reason a log
file won't write?

Daniel

On Fri, May 27, 2011 at 7:29 AM, sebb <se...@gmail.com> wrote:
> On 27 May 2011 14:17, Daniel Watrous <da...@gmail.com> wrote:
>> I had actually tried that before mailing to the list. I just tried it
>> again with no change to whether cookies are sent or not.
>
> In that case, you'll need to enable debug logging  for the Cookie
> Manager: select it and use the Menu item Help/Enable Debug
>
> Output will be in the log file.
>
>> I can't find the log file, but here's my java version:
>
> Unless you override the location in the jmeter.properties file, the
> log file will be in the directory where you started JMeter from, by
> default the bin directory, and will be called jmeter.log.
>
>> C:\Program Files (x86)\Console2>java -version
>> java version "1.6.0_20"
>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
>> Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
>>
>> C:\Program Files (x86)\Console2>
>>
>> Windows 7 x64
>>
>> thanks,
>>
>> Daniel
>>
>>
>>
>> On Fri, May 27, 2011 at 3:03 AM, sebb <se...@gmail.com> wrote:
>>> On 27 May 2011 08:48, sebb <se...@gmail.com> wrote:
>>>> On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I've been trying to setup a jmeter program to test a wordpress plugin.
>>>>> However, I can't get the login to work. It appears to be sending the
>>>>> cookies back correctly when the login is sent, but they don't get
>>>>> picked up by the cookie manager.
>>>>>
>>>>> I've been searching for a while and looked at dozens of examples.
>>>>> Maybe you can spot what I've done wrong from these screenshots:
>>>>>
>>>>> http://screencast.com/t/EW1zAgvlK
>>>>> http://screencast.com/t/2i8dTyBh
>>>>> http://screencast.com/t/fd5dGPvCb
>>>>
>>>> The Cookie Manager is set to require RFC2109 cookies; these have a
>>>> specific format that is not always followed by servers (or browsers).
>>>>
>>>> The default is supposed to be "compatibility" mode, try using that.
>>>>
>>>> What version of Java are you using? This will be shown near the start
>>>> of the jmeter.log file, e.g.
>>>>
>>>> java.version=1.5.0_22
>>>> java.vm.name=Java HotSpot(TM) Client VM
>>>>
>>>> I've just noticed that the default when adding a new Cookie Manager is
>>>> set correctly to "compatibility" (first option) when using that
>>>
>>> Actually it's the last option when using Java 1.5, first when using
>>> 1.6 - which is where the problem lies ...
>>>
>>>> version, however when using
>>>>
>>>> java.version=1.6.0_25
>>>> java.vm.name=Java HotSpot(TM) Client VM
>>>>
>>>> which is the current Java version it is set to "rfc109" (the last option).
>>>>
>>>> This is odd, since the code specifically tries to set "compatibility" mode.
>>>> Looks like there may be a Java bug (or at least a change in behaviour).
>>>
>>> It's a change in Java behaviour - the order of cookie policies is
>>> different, because of internal changes to the libraries.
>>>
>>> JMeter incorrectly relies on the order of the entries. Oops.
>>>
>>> However, there's an easy work-round - just change the policy to compatibility.
>>>
>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Daniel
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 27 May 2011 14:17, Daniel Watrous <da...@gmail.com> wrote:
> I had actually tried that before mailing to the list. I just tried it
> again with no change to whether cookies are sent or not.

In that case, you'll need to enable debug logging  for the Cookie
Manager: select it and use the Menu item Help/Enable Debug

Output will be in the log file.

> I can't find the log file, but here's my java version:

Unless you override the location in the jmeter.properties file, the
log file will be in the directory where you started JMeter from, by
default the bin directory, and will be called jmeter.log.

> C:\Program Files (x86)\Console2>java -version
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
>
> C:\Program Files (x86)\Console2>
>
> Windows 7 x64
>
> thanks,
>
> Daniel
>
>
>
> On Fri, May 27, 2011 at 3:03 AM, sebb <se...@gmail.com> wrote:
>> On 27 May 2011 08:48, sebb <se...@gmail.com> wrote:
>>> On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> I've been trying to setup a jmeter program to test a wordpress plugin.
>>>> However, I can't get the login to work. It appears to be sending the
>>>> cookies back correctly when the login is sent, but they don't get
>>>> picked up by the cookie manager.
>>>>
>>>> I've been searching for a while and looked at dozens of examples.
>>>> Maybe you can spot what I've done wrong from these screenshots:
>>>>
>>>> http://screencast.com/t/EW1zAgvlK
>>>> http://screencast.com/t/2i8dTyBh
>>>> http://screencast.com/t/fd5dGPvCb
>>>
>>> The Cookie Manager is set to require RFC2109 cookies; these have a
>>> specific format that is not always followed by servers (or browsers).
>>>
>>> The default is supposed to be "compatibility" mode, try using that.
>>>
>>> What version of Java are you using? This will be shown near the start
>>> of the jmeter.log file, e.g.
>>>
>>> java.version=1.5.0_22
>>> java.vm.name=Java HotSpot(TM) Client VM
>>>
>>> I've just noticed that the default when adding a new Cookie Manager is
>>> set correctly to "compatibility" (first option) when using that
>>
>> Actually it's the last option when using Java 1.5, first when using
>> 1.6 - which is where the problem lies ...
>>
>>> version, however when using
>>>
>>> java.version=1.6.0_25
>>> java.vm.name=Java HotSpot(TM) Client VM
>>>
>>> which is the current Java version it is set to "rfc109" (the last option).
>>>
>>> This is odd, since the code specifically tries to set "compatibility" mode.
>>> Looks like there may be a Java bug (or at least a change in behaviour).
>>
>> It's a change in Java behaviour - the order of cookie policies is
>> different, because of internal changes to the libraries.
>>
>> JMeter incorrectly relies on the order of the entries. Oops.
>>
>> However, there's an easy work-round - just change the policy to compatibility.
>>
>>>
>>>> Thanks in advance.
>>>>
>>>> Daniel
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by Daniel Watrous <da...@gmail.com>.
I had actually tried that before mailing to the list. I just tried it
again with no change to whether cookies are sent or not.

I can't find the log file, but here's my java version:

C:\Program Files (x86)\Console2>java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

C:\Program Files (x86)\Console2>

Windows 7 x64

thanks,

Daniel



On Fri, May 27, 2011 at 3:03 AM, sebb <se...@gmail.com> wrote:
> On 27 May 2011 08:48, sebb <se...@gmail.com> wrote:
>> On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
>>> Hello,
>>>
>>> I've been trying to setup a jmeter program to test a wordpress plugin.
>>> However, I can't get the login to work. It appears to be sending the
>>> cookies back correctly when the login is sent, but they don't get
>>> picked up by the cookie manager.
>>>
>>> I've been searching for a while and looked at dozens of examples.
>>> Maybe you can spot what I've done wrong from these screenshots:
>>>
>>> http://screencast.com/t/EW1zAgvlK
>>> http://screencast.com/t/2i8dTyBh
>>> http://screencast.com/t/fd5dGPvCb
>>
>> The Cookie Manager is set to require RFC2109 cookies; these have a
>> specific format that is not always followed by servers (or browsers).
>>
>> The default is supposed to be "compatibility" mode, try using that.
>>
>> What version of Java are you using? This will be shown near the start
>> of the jmeter.log file, e.g.
>>
>> java.version=1.5.0_22
>> java.vm.name=Java HotSpot(TM) Client VM
>>
>> I've just noticed that the default when adding a new Cookie Manager is
>> set correctly to "compatibility" (first option) when using that
>
> Actually it's the last option when using Java 1.5, first when using
> 1.6 - which is where the problem lies ...
>
>> version, however when using
>>
>> java.version=1.6.0_25
>> java.vm.name=Java HotSpot(TM) Client VM
>>
>> which is the current Java version it is set to "rfc109" (the last option).
>>
>> This is odd, since the code specifically tries to set "compatibility" mode.
>> Looks like there may be a Java bug (or at least a change in behaviour).
>
> It's a change in Java behaviour - the order of cookie policies is
> different, because of internal changes to the libraries.
>
> JMeter incorrectly relies on the order of the entries. Oops.
>
> However, there's an easy work-round - just change the policy to compatibility.
>
>>
>>> Thanks in advance.
>>>
>>> Daniel
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 27 May 2011 08:48, sebb <se...@gmail.com> wrote:
> On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
>> Hello,
>>
>> I've been trying to setup a jmeter program to test a wordpress plugin.
>> However, I can't get the login to work. It appears to be sending the
>> cookies back correctly when the login is sent, but they don't get
>> picked up by the cookie manager.
>>
>> I've been searching for a while and looked at dozens of examples.
>> Maybe you can spot what I've done wrong from these screenshots:
>>
>> http://screencast.com/t/EW1zAgvlK
>> http://screencast.com/t/2i8dTyBh
>> http://screencast.com/t/fd5dGPvCb
>
> The Cookie Manager is set to require RFC2109 cookies; these have a
> specific format that is not always followed by servers (or browsers).
>
> The default is supposed to be "compatibility" mode, try using that.
>
> What version of Java are you using? This will be shown near the start
> of the jmeter.log file, e.g.
>
> java.version=1.5.0_22
> java.vm.name=Java HotSpot(TM) Client VM
>
> I've just noticed that the default when adding a new Cookie Manager is
> set correctly to "compatibility" (first option) when using that

Actually it's the last option when using Java 1.5, first when using
1.6 - which is where the problem lies ...

> version, however when using
>
> java.version=1.6.0_25
> java.vm.name=Java HotSpot(TM) Client VM
>
> which is the current Java version it is set to "rfc109" (the last option).
>
> This is odd, since the code specifically tries to set "compatibility" mode.
> Looks like there may be a Java bug (or at least a change in behaviour).

It's a change in Java behaviour - the order of cookie policies is
different, because of internal changes to the libraries.

JMeter incorrectly relies on the order of the entries. Oops.

However, there's an easy work-round - just change the policy to compatibility.

>
>> Thanks in advance.
>>
>> Daniel
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: cookie manager not working

Posted by sebb <se...@gmail.com>.
On 27 May 2011 06:47, Daniel Watrous <da...@gmail.com> wrote:
> Hello,
>
> I've been trying to setup a jmeter program to test a wordpress plugin.
> However, I can't get the login to work. It appears to be sending the
> cookies back correctly when the login is sent, but they don't get
> picked up by the cookie manager.
>
> I've been searching for a while and looked at dozens of examples.
> Maybe you can spot what I've done wrong from these screenshots:
>
> http://screencast.com/t/EW1zAgvlK
> http://screencast.com/t/2i8dTyBh
> http://screencast.com/t/fd5dGPvCb

The Cookie Manager is set to require RFC2109 cookies; these have a
specific format that is not always followed by servers (or browsers).

The default is supposed to be "compatibility" mode, try using that.

What version of Java are you using? This will be shown near the start
of the jmeter.log file, e.g.

java.version=1.5.0_22
java.vm.name=Java HotSpot(TM) Client VM

I've just noticed that the default when adding a new Cookie Manager is
set correctly to "compatibility" (first option) when using that
version, however when using

java.version=1.6.0_25
java.vm.name=Java HotSpot(TM) Client VM

which is the current Java version it is set to "rfc109" (the last option).

This is odd, since the code specifically tries to set "compatibility" mode.
Looks like there may be a Java bug (or at least a change in behaviour).

> Thanks in advance.
>
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org