[racket-dev] PLaneT and proxies

So, going forward, what is the right thing? Is there something simple
we can do for now so that Norman can use planet on his school's
network, or should we wait for the net/url rewrite?

Thanks,
Robby

On Sun, Jun 20, 2010 at 4:53 PM, Eli Barzilay <eli at barzilay.org> wrote:
> [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!
>