Random HTTPS image not displaying and being aborted
This is a file that has some images displayed from my site:
https://polishwords.com.pl/dev/testAbort2.php
They are provided by HTTP and they work ok.
But in this file:
https://polishwords.com.pl/dev/testAbort.php
I show the same images but via HTTPS not HTTP and every time i refresh page (CTRL+F5) one, random, of images is not displayed and in network console it displays on red with information: aborted.
I've tried it in Chrome, Internet Explorer and Opera and everything is ok. Only in latest Firefox. I've tried with removed all privacy, restarted several times, updated FF, disabled addons, disabled extensions and its the same. Other person who has FF also reported to me the same situation.
In my server log it looks like this:
Bad load:
[22/Mar/2013:23:29:11 +0100] "GET /images/mukonczeniestudiow.jpg HTTP/1.1" 200 6705 "-" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
Good load:
[22/Mar/2013:23:30:41 +0100] "GET /images/mukonczeniestudiow.jpg HTTP/1.1" 200 6907 "https://polishwords.com.pl/dev/testAbort.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
What is the cause of this behaviour?
פתרון נבחר
Hi tomaszs, based on your log, your webserver is receiving and responding to the request, but the smaller response size suggests there is some kind of glitch. Can you spot any pattern there?
Unfortunately, I'm no expert on web servers, and I find encrypted traffic very challenging to view -- using a debugging proxy can bypass the problem you're trying to diagnose by managing the connection(s) differently.
There probably is some documentation on when Firefox aborts the request for a particular element...
Read this answer in context 👍 1כל התגובות (8)
I can replicate the problem, too.
The most obvious difference in your server logs is the referring URL, but I don't think that is required, or the server wouldn't send the other images.
Maybe the difference between HTTP and HTTPS indicates a problem with the encryption/decryption process? Is this problem new in Firefox 19?
You can check the network.http.* prefs on the about:config page.
Reset network.http prefs to the default value via the right-click context menu -> Reset if they are user set (bold).
Start Firefox in Safe Mode to check if one of the extensions (Firefox/Tools > Add-ons > Extensions) or if hardware acceleration is causing the problem (switch to the DEFAULT theme: Firefox/Tools > Add-ons > Appearance).
- Do NOT click the Reset button on the Safe mode start window or otherwise make changes.
@jscher2000 Thanks for replication. I'm really not sure. I have this for some months, but lately it is more often. Is there a way to debug encryption/ decryption?
@cor-el I have default values in network.http.*. I've tried Safe Mode, it also is the same. I'll try disable hardware now. I've tested it in default theme and disabled hardware acceleration and effect is still the same.
השתנתה ב־
I set up a page with 20 image links on my server and I do not get the same problem. Can you try this page?
@jscher2000 Thank you for creating this page. I've tested it and i don't get aborts. So it's not Firefox... but what it can be than?
פתרון נבחר
Hi tomaszs, based on your log, your webserver is receiving and responding to the request, but the smaller response size suggests there is some kind of glitch. Can you spot any pattern there?
Unfortunately, I'm no expert on web servers, and I find encrypted traffic very challenging to view -- using a debugging proxy can bypass the problem you're trying to diagnose by managing the connection(s) differently.
There probably is some documentation on when Firefox aborts the request for a particular element...
Thanks @jscher for help. I've contacted with admin of my website. He found that some odd configuration in slowloris did this thing. He disabled it so now it seems everything came back to normal. Thanks again.
Thanks for reporting back. It's a bit distressing that the server configuration saw Firefox as creating undesirable connections, but the other browsers were fine. Hopefully not an issue for too many sites.