World: r3wp

But yes, Josh, it seems like correct order. I give my vote to proxy. 
Dunno how many folks work in companies behind the proxy, but because 
there is not user.r by default, nor there is some abilitiy to launch 
desktop, the plug-in should do as much as possible, in regards to 
correctly detect proxy ...

Josh, that looks good to me.  Proxy would be good.

Josh, I believe the Proxy support is really needed and obviously 
that could be used in REBOL3 for universal use.  I hope you implement 
both kerberos and NT LM Authentication.  I know that Doc Kimbell 
already has a tested Proxy implementation using the NT LM Authentication 
on his website.

If I recall the Kerberos is the default authentication on newer MS 
operating systems and NTLM is the older legacy authentication method 
that should be incorporated to support a more diverse environment 
where Win9x  and NT 3.5-40 machines might be in use.

I know in my environment where we work with multiple customers with 
thousands of workstations in interconnected networks and extranets 
we definately need the proxy support.  We have so much proxy authentication 
going on between internal networks due to acquisitions where segmentation 
and security are still sensitive concerns.

Proxy: I've broken this sub-project down into two areas:

 1. Detection (auto-proxy, manual proxy, etc.) -- obtaining the correct 
 proxy server address for a given URL.

 2. Authentication (NTLM, Kerberos, etc.) -- authenticating with the 
 proxy server

Are there other areas you see related to proxy support?

not known to me .... but I know only a little about it ....

For NTLM authentication, isn't there some OS API to do that ?

I can't imagine that each program using Internet has it's own NTLM/Kerberos 
authentication scheme!!

Yes, I'm looking into both OS API and native methods.....

Question: On these systems that need full proxy support, are you 
running the latest OS? (i.e. WinXP SP1+, Win2k3, or WIn2k SP3+)? 
If so, there is OS support in those systems that may make this significantly 
simpler...

as for me, yes, no W9x machines ...

Am I correct in assuming that the majority of these proxy scenarios 
are just downloading HTTP/FTP files? Is there a case where you need 
upload support through proxy as well?

I am not sure what is proxy, but in our case it is kind of web cache 
... we have squid here - it looks at its local cache, and if the 
file is available locally, it is served to you by proxy, not downloading 
it from web once again ...

OK. I'm thinking about using Win32 HTTP/FTP upload/download API functions, 
which use the proxy settings set in Windows.....

what for? just to get config?

It's not exactly the REBOL cross-platform way to do things, but it 
seems to make sense for this Win32-specific scenario......

No, getting the config won't be necessary. There is full support 
in Win32 to download and upload files via HTTP and FTP, and these 
API functions automatically use the Internet Configuration in Tools->Internet 
Options, which includes proxy.....

yes, but I just don't understand, where http/ftp download/upload 
in Windows is related to rebol networking?

I need to run this by Carl, but my thinking is along the lines of 
a new option to 'read and 'write that says "use win32 HTTP/FTP API". 
If you choose that option, you get full proxy support in Windows....

With this approach, we're not building full auto-config/NTLM/Kerberos 
proxy support into REBOL, rather we're utilizing the OS API resources 
to do it all for us.

but does Windows http/ftp API limit rebol free socket capabilities 
or not? :-)

otherwise understandable, although - sockets are sockets, and imo 
similar everywhere .... I prefer the rebol way, cross platform ... 
why is that so difficult to read few registry keys and decide? The 
only problem is the proxy auto-configuration script, which in fact 
is - javascript ...

You would have only the capability of HTTP and FTP requests via Proxy, 
we're not talking about proxy-enabling the whole network stack. I'm 
not sure that makes sense anyway (i.e. if the cache server serves 
you a cached page, you're not going to communicate with the actual 
server anyway).....

The problem involves not just the auto-configuration script....there 
are also options to use multiple proxy servers, exclusion lists, 
etc. In addition, there are custom authentication schemes, i.e. NTLM 
and Kerberos, that REBOL may not fully support natively. With this 
approach, you receive full support for all of the above.

well, I let gurus to decide, maybe I am not correctly understanding 
the issue ...

ok, and what is the option to support proxy in custom build protocols? 
Will it remain?

The problem is that today REBOL is doing everything itself. It is 
making the socket connection, sending the GET command, etc. In the 
process, it has to know everything about the proxy settings and do 
everything natively.


I am proposing adding new HTTP/FTP support that uses the Win32 API. 
No more socket communication within REBOL -- instead, Win32 does 
everything, including interacting with proxies.

(When I say "No more socket communication", I mean that these options 
will not use the REBOL networking stack)

I hope that's clear.

so native raw rebol socket low-level communication will be still 
possible, right?

Sure. But not with this proxy support.

Maybe we'l fix get-net-info and you can have basic support, but no 
autoconfig or anything like that.

ok, that would be imo better ...

because what you propose is imo big change, and I am not sure it 
is good to introduce it for last R2 incarnations ...

Well, you tell me. Here are your options:

 1. Minor fix to get-net-info that reads correct registry values. 
 Does not handle auto-config, NTLM, or Kerberos.

 2. New refinements to 'read and 'write that use Win32 Internet API 
 to download and upload HTTP/FTP files. Uses whatever is supported 
 by the OS, including auto-config.

Would you prefer (1), (2), or both?

I have to have an answer fairly soon, so everyone who reads this, 
please chime in asap.

Actually, I realize that there is no problem with get-net-info with 
manual-config proxy servers. So, scratch (1) off the list above. 
The question is very simple now: Do you want a solution along the 
lines of what I proposed in #2 above?

both ... what about other platforms, Josh ... how is that with Linux 
for e.g.?

We're only talking about Win32 here.

Refinements are ok, because it can be platforms specific code ... 
but I said enough, without expertise, so I will wait for others to 
express their opinion ...

To clarify: I made a mistake above. There is nothing in get-net-info 
that needs fixing. The single question is: do you want a Win32-specific 
refinement that changes the read or write to use the Win32 HTTP/FTP 
API, and consequently enables full proxy support?

get-net-info needs fixing by its own - it looks at incorrect registry 
keys imo. Apart form ntlm, kerberos and autoconfig proxies, it would 
work, so imo it would work in 90% of cases as sufficient ...

Which registry keys are incorrect?

JoshM as long as the big picture includes the ability to authenticate 
by MS Proxy then I'm good.  This can allow me to make a plugin that 
can reach our printers via the network using their web interfaces.

Software\Microsoft\Windows\CurrentVersion\Internet Settings? Dunno, 
I don't remember ... I posted is several times already and I would 
have to inspect it ... just playing with proxy settings revealed 
that code is incorrect ..

Paul, you are OK with this support only on a Win32 client, and just 
in read/write?

Currently the lack of Proxy support that is compatible with MS Proxy 
severely limits what I can do with it in our environment at EDS.

I would like to proxy any port but I think that http, ftp is good 
for this round since the MS Proxy permissions would have to allow 
the rest anyway

Pekr, you told me before that the problem was that it ignored auto-config 
settings. But I'm already saying that there's no adding auto-config 
support to get-net-info. If you see something else that is broken 
with get-net-info, please post it. (it seems to work great here)

Paul, thank you for the feedback.