Menu

#68 Extra character(',') added to cookie/field value on refresh

1.2.1
closed
None
5
2012-10-21
2003-03-31
No

When I refresh a page and display a value that was
sent along to the server as a cookie, the value that I get
from the server is not "foo" but "foo," (note extra comma).
The page that I'm setting up the test for (we're to
change some parts of our GUI) does not do this when I
repeat the same input I'm putting into the test.

Attached test (that fails due to the presumed bug) works
as follows.
I store an email adress in a cookie and show the user
the current adress in a text input field. The user can
change the email value by entering a new adress in a
text input field and submitting.
I now try to test that I
a) get a correct default value (OK)
b) can set the value of the text field (i.e. change the
field value, then submit the form) and get the new value
displayed (OK)
c) refresh the page and see that the new setting remains
(it does, but with a ',' added at the end)

The lines that show the problem are

HtmlForm form = page1.getFormByName
("clabSettings");
HtmlTextInput textField = (HtmlTextInput)
form.getInputByName(CLabConstants.EMAIL);
// Tests no value from start
assertEquals(originalAdress,textField.getValueAttribute
());
// Test setting new adress
textField.setValueAttribute(testAdress);
// submission by javascript
HtmlPage page2 = (HtmlPage)form.submit();
form = page2.getFormByName("clabSettings");
textField = (HtmlTextInput)form.getInputByName
(CLabConstants.EMAIL);
assertEquals(testAdress, textField.getValueAttribute());
// Test that adress remains changed
page1 = (HtmlPage)webClient.getPage(url);
form = page1.getFormByName("clabSettings");
textField = (HtmlTextInput)form.getInputByName
(CLabConstants.EMAIL);
// *** BUG HERE! ***
assertEquals(testAdress, textField.getValueAttribute());

testAdress now contains "foo" and textField.getValue..
contains "foo,"

The stacktrace from the failing test is below.
I run HTMLUnit 1.2.2 , but 1.2.1 was the same
(downloaded 1.2.2 this afternoon). The test was run with
JBuilder 8's internal testrunner.

Hope that this is any help!

Yours sincerely,
Anders Egneus

junit.framework.ComparisonFailure: expected:<...> but
was:<...,>
at junit.framework.Assert.assertEquals
(Assert.java:81)
at junit.framework.Assert.assertEquals
(Assert.java:87)
at
settingspage.SettingsHTMLUnitTest.testAdress
(SettingsHTMLUnitTest.java:71)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at junit.framework.TestCase.runTest
(TestCase.java:154)
at junit.framework.TestCase.runBare
(TestCase.java:127)
at junit.framework.TestResult$1.protect
(TestResult.java:106)
at junit.framework.TestResult.runProtected
(TestResult.java:124)
at junit.framework.TestResult.run
(TestResult.java:109)
at junit.framework.TestCase.run
(TestCase.java:118)
at junit.framework.TestSuite.runTest
(TestSuite.java:208)
at junit.framework.TestSuite.run
(TestSuite.java:203)
at
com.borland.jbuilder.unittest.JBTestRunner.run
(JBTestRunner.java:206)
at
com.borland.jbuilder.unittest.JBTestRunner.initiateTest
(JBTestRunner.java:248)
at
com.borland.jbuilder.unittest.JBTestRunner.main
(JBTestRunner.java:554)

Discussion

  • Mike Bowler

    Mike Bowler - 2003-03-31

    Logged In: YES
    user_id=46756

    The cookie support is actually handled by commons-httpclient
    and not by HtmlUnit itself so the first thing I'd like you
    to try is a newer version of commons-httpclient to see if it
    fixes the problem.

    The nightly gump builds can be found at
    http://gump.covalent.net/jars/latest/jakarta-commons/

     
  • Anders Egneus

    Anders Egneus - 2003-04-10

    Logged In: YES
    user_id=746184

    I've tried using the 030410 build of commons-client (taken
    from the nightly builds on the Jakarta site), but the problem
    remains.
    (And gump.covalent.net seems to be very much offline.)

     
  • Mike Bowler

    Mike Bowler - 2003-04-14

    Logged In: YES
    user_id=46756

    If I'm reading this correctly, the problem is with the value
    being passed down in a text field, not in a cookie. Can you
    look at the html being send down from the server? The html
    as sent by the server can be retrieved with

    page.getWebResponse().getContentAsString()

    The html after it's been cleaned up by NekoHTML can be
    retrieved with

    page.asXml()

    Can you see if the comma is present in either one of these?

     
  • Anders Egneus

    Anders Egneus - 2003-04-15

    Logged In: YES
    user_id=746184

    The comma is present in both.

    The value that is put into the textfield (the value with the extra
    comma) is read by the server from a cookie, so I still think
    the problem lies in the cookies....

    I.e the flow is
    1)Browser sends submit form with value X to server
    2)Server send Set-Cookie with value X to browser (along with
    new page). (Correct values are recieved, both in the cookie
    form and as html)
    3)Browser requests page.
    4)Server responds, including textfield value "X,".

    So it seems to me either the browser stores the cookie with
    an extra comma (unlikely ?) or passes it to the server with an
    extra comma added (little more likely). I don't think the error
    is on the server side since the extra comma doesn't appear
    when I do the same submission manually.

    I looked at the cookie sent along with the server's response to
    the submit and this was correct (no comma).

    After that I tried to access the state of the HttpClient
    reponsible for the URL to look at the current cookie set after
    the form submission, but rebuilding HtmlUnit failed (I seem to
    be missing .base.testing.BaseTestCase).

     
  • Mike Bowler

    Mike Bowler - 2003-04-15

    Logged In: YES
    user_id=46756

    I'll answer the simple part first: BaseTestCase is part of
    the GSBase project (which I also maintain) and can be found
    at http://gsbase.sourceforge.net

    If the problem really is with the cookie support then we'll
    have to log a bug with commons-httpclient - none of that
    support is actually handled inside HtmlUnit. That's why I
    hoping it really isn't a cookie bug - I can fix HtmlUnit
    bugs ;-)

     
  • Anders Egneus

    Anders Egneus - 2003-04-15

    Logged In: YES
    user_id=746184

    OK, that's what I figured too (about a bug in httpclient).

    I think a prudent course now would be for me to get
    BaseTestCase and try to get access to the Cookies in
    httpclient and check what's happening there. I'm not going to
    be in the office for the rest of the week but I'll give it a shot
    next week. I'll post here once I have something more to say.

    Have a nice (bug-free :) Easter!

     
  • Anders Egneus

    Anders Egneus - 2003-04-23

    Logged In: YES
    user_id=746184

    The cookies don't have the extra comma. ( I went into the
    HttpWebConnection and looked at the Cookies in the
    HttpState).

    I'm also getting another test failure which I think may be
    caused by the same bug:
    I have another cookie which I set to a value of either X, Y or
    Z (default). The server sets a radio button depending on this
    cookie value. (The server looks for X or Y, if they are not
    present it uses Z.) Now the cookie is stored correctly as X,
    so I would expect the X button to be checked, but what gets
    checked is the default, Z.
    I now believe the test fails when http-client somehow adds a
    comma turning "X" into "X,", resulting in no match and the
    server going to the default.

    As the cookie values are correct, it looks as if something
    happens when the cookies are sent to the server. Anything
    else you can think of that I should try before we talk to the
    commons-httpclient people?

     
  • Anders Egneus

    Anders Egneus - 2003-04-23

    Logged In: YES
    user_id=746184

    The cookies don't have the extra comma. ( I went into the
    HttpWebConnection and looked at the Cookies in the
    HttpState).

    I'm also getting another test failure which I think may be
    caused by the same bug:
    I have another cookie which I set to a value of either X, Y or
    Z (default). The server sets a radio button depending on this
    cookie value. (The server looks for X or Y, if they are not
    present it uses Z.) Now the cookie is stored correctly as X,
    so I would expect the X button to be checked, but what gets
    checked is the default, Z.
    I now believe the test fails when http-client somehow adds a
    comma turning "X" into "X,", resulting in no match and the
    server going to the default.

    As the cookie values are correct, it looks as if something
    happens when the cookies are sent to the server. Anything
    else you can think of that I should try before we talk to the
    commons-httpclient people?

     
  • Anders Egneus

    Anders Egneus - 2003-04-23

    Logged In: YES
    user_id=746184

    One more thing; I've tested it using the latest (0422)
    commons-httpclient.

     
  • Mike Bowler

    Mike Bowler - 2003-04-23

    Logged In: YES
    user_id=46756

    Nothing else I can think of.

     
  • Anders Egneus

    Anders Egneus - 2003-04-30

    Logged In: YES
    user_id=746184

    Case closed. The bug isn't in HtmlUnit, it isn't in HttpClient, it
    is in the python module Cookie.py, as run on our SGI
    machines.

    :( Sorry for wasting time.

    I did a little more digging before going to the HttpClient list,
    and the output from HttpClient was legal, with only one
    comma separating cookies. I've narrowed the error down to
    pyhton module that handles cookies, and I think the problem
    lies in the python version that we use on our SGI machines
    (there are a couple of other bugs in it that are not there when
    we run python on other machines). Once I move the code to a
    Linux system expect to use HtmlUnit as part of my testing
    battery.

    Once again, thanks for taking the time to look at this. We
    can at least put it to rest.

     
  • Mike Bowler

    Mike Bowler - 2003-04-30

    Logged In: YES
    user_id=46756

    No problem - I'm just glad it's resolved.

     

Log in to post a comment.

MongoDB Logo MongoDB