Magnus, as you can imagine, these requests were not added for fun, but for an actual reason. So, please don't just remove stuff. These pre-cache requests fixed an actual bug 1572418, where the HTTPS requests timed out and the users got no response. We noticed because that this prevented our addon to be installed due to addons.json request failing, but while investigating the bug, I also noticed that the ISPDB requests also failed for the very same reason. So, this does not only affect Owl. This bug had devastating effects on our installations, but was extremely hard to find. We were looking for months for the cause. In our own tests, these requests were fast, as you saw as well. What happened was: * The DNS looking takes time * The SSL requires a OSCP fetch, which is needed only for the very first request (at a given that, for that CA). This is another network requests, which needs to complete before the SSL setup can finish and the original call can continue * The redirects you mentioned. * Many end users do not have a network that is as fast as yours All that in combination meant that we didn't see this problem, because we had DNS cached (even for new profiles), fast network etc, but a huge percentage of users had this problem. Exotic enough was that you couldn't see the problem from the server logs, because the call arrived at the server, and logged there, but was aborted by the client. Before we found this, I couldn't figure out why the install rates were so bad. After the fix shipped, install rates dramatically increased. I don't have exact numbers on ISPDB, and server logs are false as mentioned, but this would also mean that the ISPDB might have failed as well, so the effects were far beyond and broke the autoconfig for a large amount of end users. So, this pre-caching is absolutely needed, in this case. I'm only sorry we didn't do this earlier. > And to make matters worse, these get triggered a lot since it's called at the end of switchToMode That's a bug, indeed. They should be triggered exactly once at the start of the dialog. We could fix that.
Bug 1594366 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Magnus, as you can imagine, these requests were not added for fun, but for an actual reason. So, please don't just remove stuff. These pre-cache requests fixed an actual bug 1572418, where the HTTPS requests timed out and the users got no response. We noticed because that this prevented our addon to be installed due to addons.json request failing, but while investigating the bug, I also noticed that the ISPDB requests also failed for the very same reason. So, this does not only affect Owl. This bug had devastating effects on our installations, but was extremely hard to find. We were looking for months for the cause. In our own tests, these requests were fast, as you saw as well. What happened was: * The DNS lookup takes time * The SSL requires a OSCP fetch, which is needed only for the very first request (at a given day, for that CA). This is another network request, which needs to complete before the SSL setup can finish and the original call can continue * The redirects you mentioned (but they alone are not a problem, and they are no problem anymore since we make these pre-flights) * Many end users do not have a network that is as fast as yours All that in combination meant that we didn't see this problem, because we had DNS cached on our machines (even for new profiles), fast network etc., but a huge percentage of users had this problem. Exotic enough was that you couldn't see the problem from the server logs, because the call arrived at the server, and logged there, but was aborted by the client. Before we found this, I couldn't figure out why the install rates were so bad. After the fix shipped, install rates dramatically increased. I don't have exact numbers on ISPDB, and server logs are false as mentioned, but this would also mean that the ISPDB might have failed as well, so the effects were far beyond and broke the autoconfig for a large amount of end users. So, this pre-caching is absolutely needed, in this case. I'm only sorry we didn't do this earlier. > And to make matters worse, these get triggered a lot since it's called at the end of switchToMode That's a bug, indeed. They should be triggered exactly once at the start of the dialog. We could fix that.
Magnus, as you can imagine, these requests were not added for fun, but for an actual reason. So, please don't just remove stuff. These pre-cache requests fixed an actual bug 1572418, where the HTTPS requests timed out and the users got no response. We noticed because that this prevented our addon to be installed due to addons.json request failing, but while investigating the bug, I also noticed that the ISPDB requests also failed for the very same reason. So, this does not only affect Owl. This bug had devastating effects on our installations, but was extremely hard to find. We were looking for months for the cause. In our own tests, these requests were fast, as you saw as well. What happened was: * The DNS lookup takes time * The SSL requires a OSCP fetch, which is needed only for the very first request (at a given day, for that CA). This is another network request, which needs to complete before the SSL setup can finish and the original call can continue * The redirects you mentioned (but they alone are not a problem, and they are no problem anymore since we make these pre-flights) * Many end users do not have a network that is as fast as yours All that in combination meant that we didn't see this problem, because we had DNS cached on our machines (even for new profiles), fast network etc., but a huge percentage of users had this problem. Exotic enough was that you couldn't see the problem from the server logs, because the call arrived at the server, and logged there, but was aborted by the client due to the timeout. Yes, it sounds strange, but that's what happened. Before we found this, I couldn't figure out why the install rates were so bad. After the fix shipped, install rates dramatically increased. I don't have exact numbers on ISPDB, and server logs are false as mentioned, but this would also mean that the ISPDB might have failed as well, so the effects were far beyond and broke the autoconfig for a large amount of end users. So, this pre-caching is absolutely needed, in this case. I'm only sorry we didn't do this earlier. > And to make matters worse, these get triggered a lot since it's called at the end of switchToMode That's a bug, indeed. They should be triggered exactly once at the start of the dialog. We could fix that.
Magnus, as you can imagine, these requests were not added for fun, but for an actual reason. So, please don't just remove stuff. These pre-cache requests fixed an actual bug 1572418, where the HTTPS requests timed out and the users got no response. We noticed because that this prevented our addon to be installed due to addons.json request failing, but while investigating the bug, I also noticed that the ISPDB requests also failed for the very same reason. So, this does not only affect Owl. This bug had devastating effects on our installations, but was extremely hard to find. We were looking for months for the cause. In our own tests, these requests were fast, as you saw as well. What happened was: * The DNS lookup takes time * The SSL requires a OSCP fetch, which is needed only for the very first request (at a given day, for that CA). This is another network request, which needs to complete before the SSL setup can finish and the original call can continue * The redirects you mentioned (but they alone are not a problem, and they are no problem anymore since we make these pre-flights) * Many end users do not have a network that is as fast as yours All that in combination meant that we didn't see this problem, because we had DNS cached on our machines (even for new profiles), fast network etc., but a huge percentage of users had this problem. Exotic enough was that you couldn't see the problem from the server logs, because the call arrived at the server, and logged there, but was aborted by the client due to the timeout. Yes, it sounds strange, but that's what happened. Before we found this, I couldn't figure out why the install rates were so bad. After the fix shipped, install rates dramatically increased. I don't have exact numbers on ISPDB, and server logs are false as mentioned, but this would also mean that the ISPDB might have failed as well, so the effects were far beyond and broke the autoconfig for a large amount of end users. So, this pre-cache is absolutely needed, in this case. We should have done this much earlier. If only we had known. > And to make matters worse, these get triggered a lot since it's called at the end of switchToMode That's a bug, indeed. They should be triggered exactly once at the start of the dialog. We could fix that.
Magnus, as you can imagine, these requests were not added for fun, but for an actual reason. So, please don't just remove stuff. These pre-cache requests fixed an actual bug 1572418, where the HTTPS requests timed out and the users got no response. We noticed because that this prevented our addon to be installed due to addons.json request failing, but while investigating the bug, I also noticed that the ISPDB requests also failed for the very same reason. So, this does not only affect Owl. This bug had devastating effects on our installations, but was extremely hard to find. We were looking for months for the cause. In our own tests, these requests were fast, as you saw as well. What happened was: * The DNS lookup takes time * The SSL requires a OSCP fetch, which is needed only for the very first request (at a given day, for that CA). This is another network request, which needs to complete before the SSL setup can finish and the original call can continue * The redirects you mentioned (but they alone are not a problem, and they are no problem anymore since we make these pre-flights) * Many end users do not have a network that is as fast as yours All that in combination meant that we didn't see this problem, because we had DNS cached on our machines (even for new profiles), fast network etc., but a huge percentage of users had this problem. Exotic enough was that you couldn't see the problem from the server logs, because the call arrived at the server, and logged there, but was aborted by the client due to the timeout. Yes, it sounds strange, but that's what happened. Before we found this, I couldn't figure out why the install rates were so bad. After the fix shipped, install rates dramatically increased. I don't have exact numbers on ISPDB, and server logs are false as mentioned, but this would also mean that the ISPDB might have failed as well, so the effects were far beyond and broke the autoconfig for a large amount of end users. So, this pre-cache is absolutely needed, in this case. We should have done this much earlier. If only we had known. > And to make matters worse, these get triggered a lot since it's called at the end of switchToMode That's a bug, indeed. They should be triggered exactly once at the start of the dialog. We could fix that. It's sufficient just to move these calls.