bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.
Please report any other irregularities here.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Build ID: 20150401154227 Steps to reproduce: I can't tell you what causes this, only that it happens for some users and not others (even two sessions on the same machine therefore using exactly the same version of Firefox). It seems to be the condition described at the end of https://bugzilla.mozilla.org/show_bug.cgi?id=769994 - it is not related to autocomplete but causes https to be forced for a site which is not actually forcing SSL (or, in my case, where there is no SSL certificate for that site) On the machines/user accounts where it goes wrong, type or paste blah.someurl into the address bar and hit return. Note: I do not believe that the user has to have typed https://blah.someurl at any time for this to happen. However, it seems probable that it only occurs if someurl itself *does* have an https redirect. Actual results: It gets changed to https://blah.someurl blah.someurl:8040 also gets changed to https://blah.someurl:8040 Expected results: It should still be blah.someurl, or http://blah.someurl blah.someurl:8040 should stay the same or become http://blah.someurl:8040 As stated in 769994, the problem still occurs with browser.urlbar.autoFill -> false browser.urlbar.autocomplete.enabled -> false Clearing history also does not cure it.
is it reproducible easily? Do you have better STR? If not, it will hard to debug.
Component: Untriaged → Location Bar
Its easily reproducible for the users that it is happening with but unfortunately I've as yet no idea how to make it happen for someone else. Two users accessing the same site from different sessions running concurrently on the same computer get different behaviour, so it is presumably something getting stored in the profile. However, nothing was deliberately done to make the behaviour change. The symptoms were that some clients and my wife's comnputer (Mageia 4 32-bit) were initially affected. I checked using this machine (Mageia 4 64-bit) with three different user sessions and all were OK. 5 days later, one of those three user sessions developed the problem but I don't believe I did anything specific to make it happen. Both 64-bit and 32-bit Linux is susceptible but I can't confirm that Mac or Windows versions are affected.
I am hoping that more info can be gleaned from those who reported similar behaviour under https://bugzilla.mozilla.org/show_bug.cgi?id=769994.
I have confirmed that, as David noted in comment 153 of https://bugzilla.mozilla.org/show_bug.cgi?id=769994, there is no traffic to the server. Using Wireshark I see that the session which is OK initiates http after the DNS query but the session which has the problem initiates https after the DNS query - no http request even gets sent to the server.
And I confirm what comment 4 reports. Even after following the instructions in bug #769994 this POS still insists on going HTTPS. Any non-Mozilla browsers work as intended, using an HTTP connection if the URI says "http://" and HTTPS if it says "https://". On the good news front, at least the sorry bastard is not trying to redirect "ftp://" to HTTPS [ I have also discovered that the FF I'm reporting this from actually supports (read-only) SFTP ].
Update to comment 5: the culprit site has some pages that set the "Strict-Transport-Security" header (RFC 6797). Once FF has accessed one of the pages sending back the HSTS header, the whole site becomes inaccessible via HTTP. It appears to be that the RFC is rather ill thought out, as it does not explicitly consider the case where a host may want to enforce HSTS only under part of its content. The only place where I can see where it is hinted at that HSTS is intended to be applied site-wide is section 2.2 (http://tools.ietf.org/html/rfc6797#section-2.2), reading: > UAs transform insecure URI references to an HSTS Host into secure > URI references before dereferencing them. The "references to an HSTS Host" bit being the relevant part. So I retract comment 5. I'll take it up with the HSTS guys instead.
thanks for investigating - closing as its working as spec'd
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.