Closed
Bug 16258
Opened 26 years ago
Closed 26 years ago
[DOGFOOD]Form submission with post data no longer works
Categories
(Core :: Networking: Cookies, defect, P3)
Tracking
()
VERIFIED
FIXED
M11
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.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M11
Assignee | ||
Comment 1•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Summary: high characters in cookies garbled → [DOGFOOD]high characters in cookies garbled
Assignee | ||
Comment 3•26 years ago
|
||
Hmmm. From your cookie I see that your username at nytimes is ldbaron. Too bad
you didn't post your PW cookie as well. ;-)
Assignee | ||
Comment 4•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Assignee | ||
Comment 5•26 years ago
|
||
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.
Reporter | ||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Whiteboard: [PDT+] → [PDT ]
Reporter | ||
Comment 6•26 years ago
|
||
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...
Reporter | ||
Updated•26 years ago
|
Resolution: WORKSFORME → ---
Reporter | ||
Comment 7•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 8•26 years ago
|
||
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.
Assignee | ||
Comment 9•26 years ago
|
||
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.
Reporter | ||
Comment 10•26 years ago
|
||
BTW, in my testing this morning I was using yesterday's build (Linux apprunner
1999-10-25-08-M11).
Assignee | ||
Comment 11•26 years ago
|
||
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=
¤t=&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.
Assignee | ||
Comment 12•26 years ago
|
||
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.
Assignee | ||
Comment 13•26 years ago
|
||
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.
Comment 14•26 years ago
|
||
dbaron, please do not change the PDT "+" value. Resetting PDT to PDT+.
Assignee | ||
Updated•26 years ago
|
Summary: [DOGFOOD]high characters in cookies garbled → [DOGFOOD]Form submission with post data no longer works
Whiteboard: [PDT+] → [PDT ]
Assignee | ||
Comment 15•26 years ago
|
||
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.
Assignee | ||
Comment 16•26 years ago
|
||
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.
Comment 17•26 years ago
|
||
Yep...sure is...I'll get terry on it..thanks!
Reporter | ||
Comment 18•26 years ago
|
||
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?
Assignee | ||
Comment 19•26 years ago
|
||
Nope, I was using 4.7.
Assignee | ||
Comment 20•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 21•26 years ago
|
||
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.
Reporter | ||
Comment 22•26 years ago
|
||
I spun off the original report into bug 17645.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•