Yes, the goal was to reduce overall failure rates. We haven’t pushed the change that auto-updates everyone using older Installers so our current failure rate doesn’t truly tell us whether we have more people failing from bad configurations or from being behind proxies. I suppose we could push that change and watch the numbers over the next several days. What do folks think?
Meanwhile, Justin says GA is saying there is an unspecified “Error” in the analytics. Our code in theory doesn’t send just “Error” to the analytics but our code will include a “\n” when there is a failure with a stack trace. I was hoping someone with a GA account could tell us whether the “\n” is throwing off the analytics. We should probably get a new measurement of the failure rate. Is it possible to get a unique sorted list of all results from the past several days (duplicates removed)? Would folks know what proxy information to enter? Would accepting all certs be sufficiently secure given that those folks’ IT department has already taken the step to use a proxy? Is there a way for us to detect that there is a proxy? IIRC, on Windows, each browser can have its own proxy and other configuration info but Flash uses IE somehow which can be misconfigured. What is the deal on Mac? Can each browser have its own config? IOW, I think we can assume that on every computer exists one valid browser config. I figure everyone has a working browser, but it might not be the one that Flash chooses to rely on. Maybe the right answer is to have a way to fail-over to try both the player’s mechanism and the new as3httpclient and then tell folks that we are sure that Flash/AIR isn’t configured correctly and not log a failure, just like we are detecting that you can’t write to the destination directly and exiting without logging a failure (or at least I hope that’s how our code is working). Can we tell if Flash is relying on a misconfigured IE setting? Thoughts? -Alex On 7/7/15, 4:56 AM, "Nicholas Kwiatkowski" <nicho...@spoon.as> wrote: >The reason why the player's URLLoader works OK with a proxy is that it >relies on Flash's engine, which relies on the browser's engine to do these >things. The browser will ultimately take direction from the OS if there >is >a proxy in play or not and route traffic correctly in that case. We would >have to do this by hand, which is not impossible, but not a quick fix. The >other issue is that a proper proxy would proxy the SSL/TLS requests. By >all right they would issue their own certificate with the proxy listed as >a >"common name" on the certificate presented and use a locally generated, >but >trusted certificate. Again, we could do this, but it requires a large >amount of work to reinvent what we pretty much already have. > >The whole point of this exercise was to get around people's own >misconfigurations -- namely still allowing really old encryption that some >servers didn't support by default. If the number of failures is great >enough, we can implement it, but I doubt it is. Adding a separate config >screen to support proxies is doable, and then we are in proxy mode we >would >just accept all certificates would be the easiest option if we do want to >move on it. > >-Nick > >On Tue, Jul 7, 2015 at 12:50 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 7/6/15, 8:42 PM, "Nicholas Kwiatkowski" <nicho...@spoon.as> wrote: >> >> >Unfortunately, by running our own HTTP client (and bypassing the >>built-in >> >Flash/Browser client), we won't be able to automatically tunnel >>through a >> >proxy. We can build a config screen to allow a proxy to be entered, >>but >> >we >> >won't be able to verify SSL certs then (we would have to allow >>everything >> >through). Is that the direction we want to go? >> >> I remember you mentioning this before. I don’t have any background in >>the >> underlying technology. What magic do the runtimes have that we can’t >> execute with sockets? Could we make a URLLoader request to verify a >>cert? >> >> -Alex >> >>
