On 3 June 2011 05:01, Daniel Watrous <daniel.watr...@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 <shet...@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 <seb...@gmail.com> wrote: >> >>> On 3 June 2011 02:32, Deepak Shetty <shet...@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 <seb...@gmail.com> wrote: >>> > >>> >> On 3 June 2011 02:10, Deepak Shetty <shet...@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 <seb...@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 <daniel.watr...@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 <seb...@gmail.com> wrote: >>> >> >> >> On 2 June 2011 17:26, Bruce Ide <flyingrhenqu...@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-unsubscr...@jakarta.apache.org >>> >> >> >> For additional commands, e-mail: >>> jmeter-user-h...@jakarta.apache.org >>> >> >> >> >>> >> >> >> >>> >> >> > >>> >> >> > >>> --------------------------------------------------------------------- >>> >> >> > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> >> > For additional commands, e-mail: >>> jmeter-user-h...@jakarta.apache.org >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> >> >>> >> >> >>> >> > >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
