[racket-dev] PLaneT and proxies

[Moving the thread to dev.]

On Jun 20, Norman Gray wrote:
> Eli and Robby, hello.
> 
> On 2010 Jun 20, at 20:59, Norman Gray wrote:
> 
> >> Does planet go through net/url?  If so, then this is better done
> >> there.  (And if it doesn't, then it should...)
> > 
> > It does.  And yes (and yes, probably).
> 
> Come to think of it, this is possibly something that should be
> sorted out (within or via net/url) at a slightly lower level.

I think that net/url is the right level -- there's two places that use
the proxy parameter, but IIRC, that's because there some duplicated
code there -- one version for GET requests and another for a generic
method request where the method is a parameter.  It's a mess that
really need some sorting out.

There's a ton of things to do that warrant a new version: besides
proxies, it needs to properly account for things like timeouts, HTTP
errors, and redirect responses.  It would also be nice to have more
functionality for https, cookies, keep-alive connections.  I wanted to
do this for a while, but never got to it.


> On OS X, for example, there is API support for detecting whether a
> proxy has been set in the Approved Fashion (that is, within the
> Network System Preference, either manually or via automatic proxy
> configuration, and with different values depending on the current
> 'location').  See
> <http://developer.apple.com/mac/library/samplecode/CFProxySupportTool/Introduction/Intro.html>
> for sample code.
> 
> I presume there will be similar support on other unixes and on windows.

What about specifications of conditional proxies?  Ones that apply
only to some domain patterns.  And I can't think of a good way to do
this if instead of name patterns the specs are for a numeric range --
doing an explicut DNS lookup in these cases seem like a bad idea.


On Jun 20, Norman Gray wrote:
> 
> On third thoughts (!), the sequence should probably be this:
> 
>   * if $http_proxy is set, then net/url should respect it
>     unequivocally (also $no_proxy (where is this stuff
>     documented?)).  On most unixes, that'll be the beginning and end
>     of it.

I think it's important to find where it's documented.  I looked around
and didn't see anything official-looking.  It's especially important
to find out the preference of this over other facilities (as in the
OSX case).


>   * On OS X, I think that http_proxy will typically not be set
>     (it'll only be set by people who use the command-line a lot).
>     Instead, the system-wide proxy information can be obtained by
>     using system APIs, or by parsing the output of /usr/sbin/scutil.
>     That has to be reasonably dynamic, since someone might change
>     the 'location' on a laptop, say, from 'at home' to 'at work',
>     with consequent changes to the proxy.
> [...]
>   * ...plus whatever windows requires.

Yeah, the OS-specific defaults should be consulted too.  IIRC, I
looked at Windows once, and ran into some mess of a "standard" way to
get the proxy settings for a machine.  I think that the intention of
that is to make it possible for your proxy setting to be determined by
the network that it's connected too.  (And it might have been
something that required running some javascript code that can be used
to determine the proxy -- but it was a while ago, so I might be
wrong.)


>   * I seem to recall that there's a Core Foundation 'read-from-uri'
>     library call which gets all this nonsense correct,
>     transparently, but that may not be an appropriate solution here.

That would be nice -- even better if there's something equivalent on
Windows.  But we probably need our own implementation too since I
don't expect unix machines to have it.


> Damn proxies.  Sigh.

(Heh, that was my conclusion when I looked into it.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!