Closed Bug 16258 Opened 25 years ago Closed 25 years ago

[DOGFOOD]Form submission with post data no longer works

Categories

(Core :: Networking: Cookies, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: morse)

References

()

Details

(Whiteboard: [PDT+])

DESCRIPTION:  I'm having problems with cookies at http://www.nytimes.com/ .  It
never saves my login, and I have to re-login every time to access articles.  The
problem seems to be related to high characters in cookies.

It seems that the cookie gets written to cookies.txt correctly (i.e., just as it
appears in my 4.x cookies file), but either the next time apprunner is started
or the next time I go to the site or something, the high characters are
(incorrectly) stripped off.  For example, my LOGIN cookie should look like
(using less's <XX> notation for high characters):

.nytimes.com    TRUE    /       FALSE   1136073612      ID      2:<=,/0<DF>
(from my NN 4.61 cookies file)

but instead it looks like:
.nytimes.com    TRUE    /auth/  FALSE   1136073596      ID      2:<=,/0.
(from my Mozilla cookies file)

STEPS TO REPRODUCE:
 1) If you don't have an NYT login already, go to http://www.nytimes.com/, and
create one by clicking on an article off the front page and filling out the
form.  It's free.  I did this in another browser, a long time ago.
 2) Start apprunner, and go to http://www.nytimes.com/ and click on one of the
articles.
 3) Put in your login and password in the box in the upper right
 4) Look at the article.  You can browse around to all other articles, too.
 5) Exit apprunner
 6) Start apprunner again
 7) Go to http://www.nytimes.com/
 8) Click on one of the articles on the front page

ACTUAL RESULTS:
after (7):
 * my username is displayed as garbage at the bottom of the NYT home page.  It
   looks like the actual text of the cookie.
after (8):
 * It askes for registration or a UserID/PW.

EXPECTED RESULTS:
after (7):
 * my username should be displayed properly at the bottom of the home page
after (8):
 * It should properly remember the login

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-10-12-08-M11

WORKS CORRECTLY ON:
 * NN 4.61

ADDITIONAL INFORMATION:
It may be that not every login gets high characters in the cookies, but since
both of mine (ID and PW) end in <DF>, it seems they might.

I do have "Accept all cookies" checked in prefs, and bugzilla cookies work.
Status: NEW → ASSIGNED
Target Milestone: M11
See bug report 13684.  It's an entirely different bug that had been fixed bug
got re-opened in error when the symptoms of this bug were encountered.
Summary: high characters in cookies garbled → [DOGFOOD]high characters in cookies garbled
Whiteboard: [PDT+]
Putting on [PDT+] radar.
Hmmm.  From your cookie I see that your username at nytimes is ldbaron.  Too bad
you didn't post your PW cookie as well. ;-)
The behavior I am experencing is much worse than what is described here.  I
never get to step 4.  Although I have a valid account at nytimes and can log
onto it using thr 4.x browser, when I run seamonkey (built yesterday) I get an
"incorrect ID/Password combination" after step 3.  So I can't even get far
enough along to see that the high bits in cookie characters are garbled.

For what it's worth, the encoding used by nytimes on username and password in
cookies is follows:

abcdefghijklmnopqrstuvwxyz@.0123456789 (input characters)
=<¡:9876543210/.-,+*)('&%$^pnmlkjihgfe (encoded characters)

and all other input characters are invaled.  Notice that none of the encoded
characters have the high bit set with one curious exception --  "c" whose
encoding is hex A1.  Furthermore, the username (ID) and password (PW) cookie
values are terminated with hex DF, which is the character that you reported got
garbled.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Depends on: 16578
Resolution: --- → WORKSFORME
Well, after working an entire day on this bug yesterday, I pulled a fresh tree
today and guess what -- now it's working fine!  Mind you, I'm not complaining,
but it sure is frustrating when this happens.

I can't test out nytimes with todays build (due to new regression -- bug 16578),
but I was observing the same problem with netcenter webmail yesterday and with
today's build netcenter webmail is coming up just fine.  So I'm marking this bug
as works-for-me.  If, after bug 16578 gets fixed we discover that nytimes is
still not working, then please reopen this report.
Blocks: 16950
Status: RESOLVED → REOPENED
Whiteboard: [PDT+] → [PDT ]
I'm reopening this bug.  Although I was able to use the site just fine, the
bottom of the page says I'm logged in as 2:
<=,/0.  Also, there is now an extra copy of the cookies in my cookies.txt,
where they are stored *unencrypted*, with "p." added to the end of my username
and pw.


I'll try deleting those cookies and logging in again, though, because it could
have been a problem with a build from a few days ago...
Resolution: WORKSFORME → ---
I deleted all my nytimes.com cookies and the problem is exactly as originally
described.  The presence of the unencrypted cookies somehow allowed me to view
articles without logging in.
Status: REOPENED → ASSIGNED
I suspect that this bug is a duplicate of 16968.  However I'm not prepared to
mark them as duplicates just yet.  I'm pursuing both bugs right now.
The behavior I'm seeing is different than what dbaron described.  I can't even
log onto the nytimes site.  Using the same username and password that
successfully gets me in with a 4.x browser, give me an invalid password message
with 5.0

So I tried logging into netcenter webmail.  This was working the last time I
tested it out (on October 16) althoug it wasn't working a few days before that.
Well today it no longer works.  I get a message saying "fields missing".  I
captured the traffic sent to the server for both the 4.x and 5.0 browser and
compared them.  All the form-posting information was missing when using the 5.0
browser.  Well that explains why it is not working.  Now to figure out why the
form-posting information is not being sent.
BTW, in my testing this morning I was using yesterday's build (Linux apprunner
1999-10-25-08-M11).
This is definitely a regession that occured in the past few days.  On my build
of October 20 I see the following traffic being sent to the server when I try to
log onto nytimes.com

  POST /auth/continueLogin.fcgi HTTP/1.0
  host: www.nytimes.com
  accept: */*
  user-agent: Mozilla/5.0 [en-US] (Windows_NT; I)
  referer: http://www.nytimes.com/aponline/f/AP-Dow-Industrial-Changes.html
  cookie: RMID=cdd9e5d138163250
  Content-type: application/x-www-form-urlencoded; charset=ISO-8859-1
  Content-Length: 142

  URI=/aponline/f/AP-Dow-Industrial-Changes.html&Tag=/&site=&ban=&sweeps=
    &current=&FORMTYPE=DONTSAVE&User=spmorse&Password=xxx&SAVE=PASSWORD

On a build from last night the last line in the sent traffic is the cookie
header -- the content-type, content-length, and URI lines are not there.  And it
is the URI line that contains all the form-posting data (username, password) so
this explains why my nytimes login was rejected.

Now to figure out why those last lines of the traffic have suddently vanished.

And, BTW, ignore my comment above about suspecting this was a dup of 16968.  Now
that I understand more about both of these bugs, it is clear that they are
distinct bugs.
Comparing the traffic for netcenter login between my October 20th build (which
worked) and my build from last night (which failed), I see the following:

 POST /iiop/UReg2/login/loginform HTTP/1.0
 host: ureg.netscape.com
 accept: */*
 user-agent: Mozilla/5.0 [en-US] (Windows_NT; I)
 referer:http://ureg.netscape.com/iiop/UReg2/login/login?
   U2_LA=en&
   U2_BACK_FROM_CJ=true&U2_CS=iso-8859-1&
   U2_ENDURL=http://webmail.netscape.com/tpl/Subscribe/Step1&
   U2_NEW_ENDURL=http://webmail.netscape.com/tpl/Subscribe/Step1&
   U2_EXITURL=http://home.netscape.com/&U2_SOURCE=Webmail
 cookie: Reg2CookieTest=; UIDC=205.217.229.209:0940980160:330437; NSPOP=|smu9
 Content-type: application/x-www-form-urlencoded; charset=ISO-8859-1
 Content-Length: 310

  U2_USERNAME=stevemorse&
    U2_ENDURL=http%3A//webmail.netscape.com/tpl/Subscribe/Step1&
    U2_NEW_ENDURL=http%3A//webmail.netscape.com/tpl/Subscribe/Step1&
    U2_EXITURL=http%3A//home.netscape.com/&
    U2_FAILURL=&U2_LEGFAILURL=&
    U2_SOURCE=Webmail&U2_CS=iso-8859-1&U2_LA=en&
    U2_CURTIME=&U2_CURTIME=&
    U2_PASSWORD=xxx&x=42&y=13

The above is for my October 20th build.  The build from last night ends with the
cookie line -- the content-type, content-length, and the U2 lines are missing.
So this is consistent with what I saw at the nytimes site.
Here's a very simple test case that demonstrates the problem:

<html>
  <body>
    <form method=POST action="http://www.mozilla.org"
      Name
      <input type="text" name="name" value="" size=50 maxlength=60><br>
      <input type="submit" value="done">
    </form>
  </body>
</html>

Pressing on the submit button sends out the following traffic on the 0ctober 28
build but is missing the last few lines in last nights build:

 POST / HTTP/1.0
 host: www.mozilla.org
 accept: */*
 user-agent: Mozilla/5.0 [en-US] (Windows_NT; I)
 referer: file:///c|/junk/spm.htm
 Content-type: application/x-www-form-urlencoded; charset=ISO-8859-1
 Content-Length: 9

 name=morse

Copying Rick Potts on this because Gagan has just informed me that he is looking
into a related (or maybe the same) problem.
Whiteboard: [PDT ] → [PDT+]
dbaron, please do not change the PDT "+" value.  Resetting PDT to PDT+.
Summary: [DOGFOOD]high characters in cookies garbled → [DOGFOOD]Form submission with post data no longer works
Whiteboard: [PDT+] → [PDT ]
Changing summary line to reflect current state of this bug.  This is far afield
from dbaron's original reporting of "high characters in cookies garbled" or even
his reopening of the bug on October 26 with a new set of symptoms.  If, after
the form-submission problem is cleared up, any of the original symptoms are
still present then a new bug report should be opened -- this one is already too
cluttered.
Jan, that changing of PDT+ to PDT is occuring automatically whenever a change is
made to the summary line.  It just happened again when I modified the summary a
few minutes ago and I know I didn't edit the Whiteboard line.  Sounds like a bug
in bugzilla.
Whiteboard: [PDT ] → [PDT+]
Yep...sure is...I'll get terry on it..thanks!
Could it be a bug in Mozilla?  I think I may have reopened the bug using
Mozilla.  morse@netscape.com, were you using Mozilla when you modified the bug
causing the change?
Nope, I was using 4.7.
This looks like it may be a dup of the latest symptoms reported in bug 8209.
Fix for that was checked in by rpotts last night.  Am currently building a fresh
tree and will try this out to see if it fixed the bug.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Yep, rpotts check-in fixed this -- I can now log in successfully to netcenter
webmail and to nytimes.  And there is nothing on the bottom of the page saying
what I am logged in as nor extra cookies in my cookies file (as reported by
dbaron on 10-26).

Closing this report out as fixed based on rpotts check-in of last night.
I spun off the original report into bug 17645.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.