The regression occurred between milestone 0.9.5 and milestone 0.9.6. Login is possible with release build 2001101117 (0.9.5 on Win), but not with 2001112009 (0.9.6 on Win). Is there some archive of nightly builds available so I could isolate this a little further?
Well, the old daily builds are thrown away. the earliest is dated 12-26-2001, but they will also soon disappear I will try to se who's guilty :-) Thanks for... you know what :-)
Created attachment 66316 [details] Login Page, Saved This version of the login page does not submit, instead it shows the value of username/password and the value of document.cookie.
The funny thing is, when I come back to the login window, the username and password are embedded in the username and password inputs, indicating that they got to the server /somehow/. What's up with that? Does this work in IE?
This works with IE 5.5 and 6, as well as with Opera, and until Milestone 0.9.5 on Mozilla. jkeiser, I assume you got the login information from Alexandru.
the funny thing is: if you try to login and it does not work, the login window pops up again and here comes the clue - the inputs username and password are preset correctly and that is comming from the apache-server! So i'm sure is not the form! It has rather to do with the request that is sended but is also not form submission since there is no submission but a combination of cookies and window.open(...).
From my tests, it looks like the cookie is not being sent in 0.9.7. (This could be because the cookies are being created just before window.open() and the cookies are not really created yet at that point.) Let me explain how I got that data: I wrote a little tiny server and ran it on port 8086 of my machine. I put the login page at http://127.0.0.1/~john/okeyto do window.open("http://127.0.0.1:8086/php/article.phtml?issue_id=1134&rand=' + Math.random(), 'main'); The little server just takes whatever the browser sends it and puts it to a file. I took those files and that is what you see there.
Assignee: alexsavulov → morse
Component: Form Submission → Cookies
QA Contact: vladimire → tever
Alex spent some hard time hitting it too, and can confirm that the URL is the same as well as all the headers on his computer; but he was seeing the cookies sent. Still, this is the first lead we have.
Wonder if this could be related to bug 121397?
Maybe, but in bug 121397, comment #1 Christopher states he could log in using 0.9.6 (and not with 0.9.7 any more), while I could log in using 0.9.5, but not with 0.9.6 anymore (all on Win).
Can someone post exactly what cookie-manager shows for these cookies. Specifically, I want to see the hostname and also whether or not they are domain cookies (domain cookies have the label "domain" for the first field, otherwise the label is "host"). There was a change made regarding sending of domain cookies to hosts that are ip addresses, and I notice from the attachments that this is such a host.
Cookie Manager sets 3 cookies, "cookieswork" (at the very beginning), "username" and "password". For username it says: Site: www.ff-online.com Cookie Name: username Name: username Information: myusername /* did you get the login info? */ Host: www.ff-online.com Path: /php/login.phtml?page=/php Server Secure: no Expires: at the end of session Site: www.ff-online.com Cookie Name: password Name: password Information: mypassword Host: www.ff-online.com Path: /php/login.phtml?page=/php Server Secure: no Expires: at the end of session Site: www.ff-online.com Cookie Name: cookieswork Name: cookieswork Information: 12.07.2000 Host: www.ff-online.com Path: /php Server Secure: no Expires: at the end of session
Those cookies don't agree with Keiser posted traffic. In his tests he was using a local server and the hostname was an ip address. Can someone post traffic and cookie-list that are obtained from the same test.
(Those cookies were from the tests--I haven't done any 127.0.0.1 tests since then--and they are the same as the cookies that showed up in 0.9.4. I used different profiles for the tests to avoid corruption.)
If this is somehow related to bug 121397, it isn't however an exact duplicate. 2 differences: 1. This regression occurred between 0.9.5 and 0.9.6, bug 121397 between 0.9.6 and 0.9.7 2. The page in this bug works with Opera (5.x on Win32), while the one in bug 121397 seems not to work there. Unfortunately, no activity on any of the bugs. Is there anything I can do to help shed some light on this problem?
As I reported via email to the reporter, I was working on building moz to isolate bug 121397. However, that bug seems to have been fixed in the latest nightlies. In light of this I probably won't be taking the time to pull and build older versions of moz anymore, so I won't be able to look into this bug on the side. Can the reporter please check to see if this problem still exists in the latest builds?
I still see this on W2K using build 2002022503 -> definitively *no* dupe of bug 121397.
Just a thought. Reporter, what setting do you have for the cookie-acceptance pref? In particular, is it set to originating-server-only? If so, this could be the same as bug 134203.
Status: NEW → ASSIGNED
Cookie acceptance is set to "Enable all cookies". I was suspecting (hoping) this could be related to bug 134203, too, but it tried 2002040903 (which should already have picked up the fix for that bug) and this bug (121355) is still here. BTW: morse, did you get my mail with username/pwd for testing?
> BTW: morse, did you get my mail with username/pwd for testing? Yes I did. But since this bug is neither nsbeta1 nor adt, I won't be looking at it for quite a while. If you want to escalate things, then nominate it.
Nominating adt1.0.0 and nsbeta1. Rationale: This is a regression since Netscape 6.2.x/Mozilla 0.9.5, the paid content of the page is not reachable using any newer build, and there is no workaround available. The site itself is the online-version of a weekly news-magazine read in parts of northern Italy and Austria.
Keywords: adt1.0.0, nsbeta1
Nav triage team needs info: Is this a top 100 site, or can this problem be reproduced on any top 100 site? Could this be an evangelism problem? cc Evelyn, Jaime for input.
Whiteboard: [need info]
> Nav triage team needs info: > Is this a top 100 site, No. > or can this problem be reproduced on any top 100 site? I would not know. > Could this be an evangelism problem? Since the website worked with Netscape 6.0-6.2.2 (everything based on Mozilla before 0.9.6), I guess that it is not the website that is broken. Evangelizing website changes because of our own bugs is a little embarrassing (if we have to admit why we do so) and does not seem like a good way to get Mozilla/Netscape treaded as an equivalent browser. But if that is the way to go for now, I can find out contact information.
Here is the contact information: Content providers, i.e. the magazine people: firstname.lastname@example.org Site designers/programmers: http://www.web.by.com/, email: email@example.com
This one is awfully familiar which is why I wanted to check something, as I said above. However I can't find the reference that I'm looking for. cc'ing darin because he might recall. The problem is the unquoted slash in the query string. Because of that slash, the url parsing is reporting the path as being spm2.htm?x=/ in the above example, whereas is should actually be null (there is no pathname preceding the filename). And this incorrect reporting of the path is making the cookie testing fail because it looks like the two files are not on the same path and hence can't share cookies. If the slash were not in the query string (or if it were there but quoted), this example would work fine. darin, there was another bug that was fixed recently involving unquoted slashes in query string but I can't find it. Do you recall which one it was? I don't recall if we closed it out as invalid, or if we actually put in a patch for it. If the latter, that patch might be what is breaking things here.
BTW, I should mention that the problem is on the site. A query string may not contain unquoted slash characters. I believe that was all spelled out in the bug report that I can't locate.
Thanks Steve. nsbeta1-, should we give this to evangelism?
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info]
Not so quickly. There still an unanswered question here which I want to better understand before passing this off. It might be that I fix we made recently caused a regression. I won't know until I find that other bug report.
Thank you, Steve. I guess you don't mean bug 91922 (improper handling of %2F in query string on Windows), do you? Mozilla's behavior in this matter changed between the 0.9.5 and the 0.9.6 release from accepting to not accepting the slash any more (as if I had never written this before). I could verify this with your testcase. Unfortunately, my tries to find something useful about this in bugzilla were not successful so far.
OS: Windows 2000 → All
No, that's not the bug report I had in mind. I wasn't aware of that one and, in fact, it seems to be just the opposite problem. In that case the slash in the query string was properly escaped and the escaping caused problems. The report that I'm thinking of caused problems because the slash was not escaped, which is exactly what is happening in this report. And the report I'm thinking of involved cookies. I'm very frustrated in not being able to find it because I looked into it just recently and I know it had the answers we are looking for. If you can locate it, it would be very helpful.
Aha -- I found it. It's bug 62348. And it even has a patch in it. Even though the error is on the websites, it would be easier to make the browser more tolerant rather than consider this as an evangelism issue. Especially since that bug report already has a patch in it. There will probably be many sites that we are going to fail on because of this. Therefore I'm going to recommend that bug 62348 be considered for nsbeta1. *** This bug has been marked as a duplicate of 62348 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.