Giters

falling-sky / source

Main source for falling-sky. Mostly HTML, JavaScript.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Json test not accessible due to CORS

karmakaze opened this issue · comments

commented

The test-ipv6 is very useful in determining web user IPv6 connectivity. We're using it to identify end-users on iOS/Safari that have a semi-broken IPv6 websocket implementation.

The endpoints
https://ipv4.lookup.test-ipv6.com/ip/?asn=1&testdomain=test-ipv6.com&testname=test_asn4
and
https://ipv6.lookup.test-ipv6.com/ip/?asn=1&testdomain=test-ipv6.com&testname=test_asn6
are extremely useful but do not work from non-origin domains.

Would it make sense to add a CORS header Access-Control-Allow-Origin: * for the https://test-ipv6.com site and mirrors?

commented

This call is a JSONP style call - it requires a callback name parameter. You can use it today.

If I were to change things I’d want all the mirror sites around the world to change too. However, getting them to update the custom Apache module is difficult and very time expensive for me to manage.

commented

I'm aware that this endpoint supports a JSONP response form. It however already supports a JSON response form:

https://ipv4.lookup.test-ipv6.com/ip/?asn=1&testdomain=test-ipv6.com&testname=test_asn4&callback=cb

returns cb({...}) whereas

https://ipv4.lookup.test-ipv6.com/ip/?asn=1&testdomain=test-ipv6.com&testname=test_asn4

returns {...} with the content-type: content-type: application/javascript;charset=UTF-8

Since it already has JSON support, this issue is to enable adding CORS headers. Please re-open the issue if that seems reasonable.

commented

I have enabled it only on lookup.test-ipv6.com, which is just two VMs that I personally operate. Note that they aren't exactly scalable, but good enough for test-ipv6.com's expected traffic. If you plan on sending any significant volume, we should talk privately, jfesler@gigo.com.

Mirror sites will not be done. Why? Steps required:

  • Simple code change to mod_ip
  • Sending mail to all known mirrors (currently 53)
  • Nagging every few weeks, for a period of 3 months
  • Drop all mirrors who didn't update (last one was ~20%)
  • Finally consider the feature ready
  • Lament over the hours I spent auditing and nagging (~15h)

Changes to the apache mod_ip handler are not automatic. Those changes require the mirror operators to set aside time, compile, test, deploy. It doesn't sound like much, but getting their attention on this is. And it's a huge drain for me to make any change that involves getting people to change their web server configuration or modules.

The above is not theoretical - I've gone through it a couple times. It's bad enough that I'll jump through hoops to avoid it. It's bad enough I periodically consider reducing the number of mirrors, perhaps only running a few of my own. But, I can't get the coverage that others provide, ensuring that clients around the world have a nearby mirror with good connectivity to avoid interfering with the tests.