Closed Bug 792856 Opened 7 years ago Closed 7 years ago
HTTPS address is preferred from address bar even when it is an error (e
.g . 403 Forbidden)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1 Build ID: 20120905151427 Steps to reproduce: 1. Visit https://www.example.com/ , which returns a 403 Forbidden status code. 2. In the address bar, begin typing 'www.exam', 'www.example.com/' is shown in the address bar with 'ple.com/' highlighted 3. Press enter to load the page Actual results: https://www.example.com/ is loaded Expected results: http://www.example.com/ should be loaded because https://www.example.com/ is an error page. Should only prefer previously-visited HTTPS addresses over their HTTP counterpart if the HTTPS address had returned a successful status code (e.g. not 403, 404, etc)
The possible idea is to not mark error pages as typed, even they were. Though has to be evaluated in the possibility the page may be only temporary unavailable, should we care?
Status: UNCONFIRMED → NEW
Component: Untriaged → Location Bar
Ever confirmed: true
I think it probably depends on the error code. My thoughts are: 400 Bad Request, 403 Forbidden, 404 Not Found, 410 Gone should be considered errors (i.e. don't prefer the HTTPS address over the HTTP address) but 401 should be considered OK (i.e. *do* prefer the HTTPS address over the HTTP address). So a rule like "all 4xx count as errors" is too simple. 5xx shouldn't be considered errors (i.e. *do* prefer the HTTPS address over the HTTP address) as they are often transient errors. I'm undecided on which other response codes should be taken to indicate an invalid HTTPS address.
Maybe a duplicate of bug 769348
I don't think it's a duplicate of bug 769348 as that relates to FF selecting undesired, *but valid*, variants (e.g. ftp servers that do exist). This bug relates to selecting *invalid* variants (i.e. https variants that return error status codes). Following on from Marco Bonardo's request in that bug to test the nightly against that bug, I can confirm that this bug's unwanted behaviour still exists in Nightly 18.0a1 (2012-09-25), which perhaps strengthens the case for this not being a duplicate.
(In reply to Jon Green from comment #4) > Following on from Marco Bonardo's request in that bug to test the nightly > against that bug, I can confirm that this bug's unwanted behaviour still > exists in Nightly 18.0a1 (2012-09-25), which perhaps strengthens the case > for this not being a duplicate. Yes, that change cannot relate to error pages, my request was cause now you can enforce a protocol. But that has nothing to do with server errors.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 769994
You need to log in before you can comment on or make changes to this bug.