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.