-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CT: net::ERR_FAILED in phet-io-wrappers-tests #185
Comments
https://stackoverflow.com/questions/22665232/what-can-cause-chrome-to-give-an-neterr-failed-on-cached-content-against-a-ser helped me reproduce this while recording chrome network traffic. It was important to reproduce with a link like this (from CT) and this chrome recording link chrome://net-export |
Here is the log viewer for the failed request:
That is not very helpful to me, but I guess it is good to note. @mattpen, could we please work to brainstorm what may be happening here? I can't figure out if this is even getting the nginx. |
It looks like the 404 is correct to me. Did a snapshot get deleted or renamed somehow?
|
@mattpen, @chrisklus, @zepumph had a meeting. In it, we looked into nginx error logs and found a pretty consistent one like:
Then after googling we updated to nginx 1.22, and it went away, but that didn't solve our problem. We didn't make any more progress in the chrome net-export tool, as there really isn't much else to see there. The best we did was found that this is only a problem with Chrome, and not firefox or safari, so we would like to switch bayes to use firefox, as a workaround, and see if that silences these errors. Thanks @mattpen and @chrisklus for all your time! |
After trying to run firefox on bayes (RHEL 7), I ran into an error that pointed me to https://access.redhat.com/solutions/2853631 and https://bugzilla.redhat.com/show_bug.cgi?id=1369859. So until we figure out the RHEL 8 upgrade, I'm just going to turn off the bayes clients. |
All chrome clients have been turned off on bayes. Unassigning until https://github.com/phetsims/special-ops/issues/242 is done. |
Interestingly enough. It looks like this has to do with using https://sparky.colorado.edu as a URL, because on sparky for its local clients, I swapped from 127.0.0.1 and ran into this again. So perhaps this has something to do with things outside of our node server. I'm not sure how to proceed, but would like to touch base with @mattpen one more time. |
Does it happen if you use 128.138.93.172? If not, it may be a problem with the DNS server or queries. If it does happen with this IP ... I'm really confused as it looks like after the DNS lookup it would essentially follow the same path as localhost or 127.0.0.1.
|
I'll try it out! |
When trying to use
This is not an issue when using clients directly from sparky. I am also able to ping the IP address. Thoughts? |
I think we might need to generate a new SSL cert that has the IP as an alternate name. Maybe we should just use HTTP instead of SSL. I wonder if there is a way we can allow HTTP from a specific set of IPs instead of the internet in general. Or maybe it just doesn't even matter, the phet sims are accessible over http and we have no plan to change it, e.g. http://phet.colorado.edu/sims/html/friction/latest/friction_all.html |
I am blocked by http because for testing, I need to be able to postMessage to https://phet-io.colorado.edu over in https://github.com/phetsims/phet-io/issues/1944. Looks like http://phet-io.colorado.edu/sims/phet-io-test-sim/2.12.0/ redirects to https, so perhaps I'm still blocked about this? |
CT has not been testing since yesterday becuase of the altnames issue:
How do we regenerate the SLL cert? Want to pair on this? |
The alternative I think would be to reach out to OIT about the general DNS issue, which I believe we both barely understand, and see if we get traction on that. Do you have a preference? |
I changed the default :80 block for the nginx.conf file so it doesn't do SSL escalation:
I confirmed that this is no longer enforcing redirects from http://128.138.93.172 to https://sparky.colorado.edu.
@zepumph -- I hope this might be helpful. If it's not and you'd like to revert, the previous version of the conf is saved in I don't understand the comment about http->https redirects for phet-io.colorado.edu. Are you getting the net err failed problems for that domain too? If so, this is likely a browser issue and not a webserver or DNS server problem. If we need to add the ip as an alt name to the SSL cert for sparky, we can request a new cert from OIT then install it. My notes that briefly describe how to do this are here: https://github.com/phetsims/website#updating-an-ssl-cert . I'm not sure if these will be useful to people who are not Matt Pennington, OIT's instructions for requesting certs are here: https://oit.colorado.edu/services/web-content-applications/ssl-certificates and Nginx instructions for installing certs are here: http://nginx.org/en/docs/http/configuring_https_servers.html. But I'd be happy to update the cert. |
After discussing with @mattpen:
Thanks @mattpen for working with me so much on this. |
New SSL cert with the IP included as an SAN (Subject Alternative Name) has been requested with OIT. |
In https://github.com/phetsims/phet-io/issues/1944#issuecomment-1612160549 this was solved by |
Let me know when the static IP is ready for testing on https. |
Looks like IP Addresses are not eligible to add as SANs in the Sectigo tool provided by CU. So we won't be able to test https://{{ip address}}, unless we self-sign a cert which is likely to raise additional errors. |
I believe that once we have upgraded bayes over in https://github.com/phetsims/special-ops/issues/242 this issue is worth another look. It would be nice to have bayes clients for CT back in here. |
About half of the errors on CT are this right now
The text was updated successfully, but these errors were encountered: