Closed
Bug 26117
Opened 25 years ago
Closed 24 years ago
HTTP Referer needs trailing / (Webbased email login failure)
Categories
(Core :: Networking, defect, P3)
Core
Networking
Tracking
()
VERIFIED
WORKSFORME
M16
People
(Reporter: mhearn, Assigned: jud)
References
()
Details
(Whiteboard: [NEED INFO][PDT-])
When I try and login (with correct password etc.) to 020 webmail I am simply chucked back into the login screen when I click enter. It works with other browsers and this is not related to my username/password which have worked fine for months.
Comment 3•25 years ago
|
||
could be secure server issue. Mozilla has the same problem with hotmail.com for example
Comment 4•25 years ago
|
||
This is what we send to the server: POST /cgi/checklogin.pl HTTP/1.0 Host: mail.020.co.uk User-Agent: Mozilla/5.0 [en-US] (Linux; I) Accept: */* Accept-Language: en Referer: http:///mail.020.co.uk cookie: CSLAuthLR=http://mail.020.co.uk/020.html Content-type: application/x-www-form-urlencoded Content-Length: 112 referer=%2F020.html&config=system.cfg&CSL_domain=020.co.uk&submit2=ok&CSL_username=mozilla&CSL_password=password Notice that we are sending the HTTP_REFERER: Referer: http:///mail.020.co.uk But Nav sends this HTTP_REFERER: Referer: http:///mail.020.co.uk/ I modified our post to add the trailing / and things just magically worked. Gagan, this seems like an HTTP issue - possibly related to bug 1582 - can you take a look? Thanks!
Assignee: pollmann → gagan
Severity: minor → normal
Component: Form Submission → Networking
OS: Windows 98 → All
Hardware: PC → All
Updated•25 years ago
|
Summary: Webbased email login failure → HTTP Referer needs trailing / (Webbased email login failure)
Putting on PDT- radar for beta1. Unless you can show broader impact.
Whiteboard: [PDT-]
warren says that this should probably be put in webshell along with http:// fixup... to jud.
Assignee: gagan → valeski
Updated•24 years ago
|
Target Milestone: M14 → M15
Assignee | ||
Comment 7•24 years ago
|
||
cc'ing andreas. We might be able to get away with arbitrarily appending a trailing slash to HTTP urls in the webshell, but we can't do it for all urls. FTP for example applies meaning to whether or not the *user* ended the url with a slash.
Status: NEW → ASSIGNED
Comment 8•24 years ago
|
||
Someone please fill me in on the referer stuff. Why do we send Referer: http:///mail.020.co.uk Why the three slashes? This would be a http url without a host and only a file name mail.020.co.uk, which correctly has not trailing /. If we would send http://mail.020.co.uk the parser would correctly add the trailing / automatically. What is the correct syntax on the referer stuff?
Assignee | ||
Comment 10•24 years ago
|
||
this works now. I'm sure URL parsing changed such that we stick on the ending slash.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 11•24 years ago
|
||
I don't think there were any changes to URL parsing. There must be another explaination.
Comment 12•24 years ago
|
||
Reopening bug. This bug still exists on: - MacOS9 2000-04-27-08-M16 Commercial Build - Linux6 2000-04-27-09-M16 Commercial Build - Win98 2000-04-27-09-M16 Commercial Build
Comment 13•24 years ago
|
||
Not sure if it's related, but when Mozilla follows a link to http://validator.w3.org/check/referer, it apparently does not send the referrer (or does not send it correctly). The W3C page opens up as if no referer had been sent. Last verified with 2000050820 on Windows 2000 Professional.
Comment 15•24 years ago
|
||
The http referer is working correctly now, per bugzilla#1582. Marking VERIFED WORKSFORME on: - MacOS9 2000-05-18-09-M16 Commercial Build - Linux6 2000-05-18-09-M16 Commercial Build - Win98 2000-05-18-09-M16 Commercial Build
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 17•22 years ago
|
||
Mass removing self from CC list.
Comment 18•22 years ago
|
||
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in
before you can comment on or make changes to this bug.
Description
•