Loading isolates from localhost doesn't work with a proxy

[nex3]

For details, see issue #15161. Here's a simple script that loads an isolate from localhost:

    void main() {
      HttpServer.bind('localhost', 0).then((server) {
        server.listen((request) {
          request.response.write("fn() => print('in isolate');");
          request.response.close();
        });

        new File('/tmp/test.dart').writeAsStringSync('''
    import "http://${server.address.host}:${server.port}/file.dart";

    main() => fn();
    ''');

        Isolate.spawn(bufferedSpawn, '/tmp/test.dart');
      });
    }

    bufferedSpawn(uri) => Isolate.spawnUri(Uri.parse(uri), [], null);

[nex3]

Marked this as blocking #15161.

[sgjesse]

Saving the code in spawn_uri.dart, and running with a proxy fails:

$ http_proxy=xxx dart spawn_uri.dart

Uncaught Error: IsolateSpawnException: 'SocketException: Failed host lookup: 'xxx' (OS Error: Name or service not known, errno = -2)'file:///tmp/test.dart': error: line 1 pos 5: library handler failed
...

However setting no_proxy to localhost makes it run:

$ http_proxy=xxx no_proxy=localhost dart spawn_uri.dart
in isolate

According to issue #15161 setting the no_proxy to contain localhost does not solve the problem though.

Under all circumstances we should add special handling of at least loopback addresses in dart:io, so that these addresses are not accessed through a proxy by default no matter what is in no_proxy.

---

Removed Priority-Unassigned, Library-Isolate, Area-Library labels.
Added Priority-Medium, Area-IO labels.

[sgjesse]

I have looked into how the http_proxy and no_proxy settings are handled by wget an curl. Both of these programs does not have any special handling of loopback addresses, and one needs to explicitly use no_proxy, e.g.

$ http_proxy=proxyserver:1008 no_proxy=localhost curl http://localhost:8080/index.html

Here the no_proxy setting is required to access the HTTP server running on localhost. The same is the case for wget.

This is the same for browser proxy configuration scripts, see http://findproxyforurl.com/example-pac-file/ for bypassing the proxy server for loopback connections.

Based on that I am not sure we should add special handling of loopback to the Dart HTML proxy handling.

---

Added Waiting label.

[nex3]

I have no strong opinion on respecting the HTTP proxy for dart:io requests, although it's difficult for me to see the utility. For isolates, though, it's clear that using them to load Dart code from the current process is an important use case, and respecting the proxy in that case causes serious problems that are very difficult to debug. Any user with a proxy will have pub fail with a message that doesn't make it at all obvious what the problem is.

[kevmoo]

Removed Area-IO label.
Added Library-IO, Area-Library labels.

[Bikeman868]

I notice that this thread is from 2014 and I am still having this issue in 2017. Was this issue never fixed? and is there a workaround?

[kevmoo]

@Bikeman868 – another option is to use data: URIs – then you don't even need to spin up a server.

[Bikeman868]

@kevmoo I have quite good knowledge of the Dart language but very little knowledge of how the Pub tool works or how to configure it. I just use pub get and pub build and that's it. I have no clue what data: URIs are and have never spun up a server.

My issue is described in dart-lang/pub#1677

[kevmoo]

Can I close this re dart-lang/pub#1677 (comment) ?

[Bikeman868]

I closed it already (12 days ago)

…

On Wed, Sep 13, 2017 at 2:07 PM, Kevin Moore ***@***.***> wrote: Can I close this re dart-lang/pub#1677 (comment) <dart-lang/pub#1677 (comment)> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15215 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFaom-kTLZ2ktNMAGb330voyBzoTWBeOks5siEQlgaJpZM4O3AWa> .

[Bikeman868]

Oh, this is not the issue in your link. Yes, please close this issue.