World: r3wp

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.

Sure thing Josh.

I want to make it clear that we are not promising these refinements 
or anything along those lines.. We may nix the whole idea. We just 
want to get your feedback on the idea. Would you like refinements 
that use the Win32 HTTP/FTP API, including proxy support?

I would prefer os-level reading. That may also fix Brianh's problems 
re illegal downloads, i guess this data is cached in browser-cache 
of ie. Maybe read-thru could be changed to use that instead of sandbox. 
Easier to know what is on the system.

Re crosssplatform: i see no problem. if i read-thru url, i want that 
contents. it is not interesting how that works technically. (Except 
for protocoll-related hacking, but i really do not need that for 
the simple solution)

Volker, yes, OK....got it. But you won't have full proxy support 
on any other platform (for now).

Is that OK?

Said it wrong. os-level means #2,

where the reading is done completely by ois.

Yes, I understand. But we're not talking about OS-level reading on 
Mac or Linux.

But if you have the refinements that could be done.

Yes, at some point in the future.

Yes. Well, linux-rebol is somewhat restricted usually..

And i guess you find similar apis on this systems.

Yes, true.

OS/X would be more important. But i guess it has similar apis too.

On Linux gnome and kde have some layer to allow urls everywhere. 
I guess they have the neccessary apis  too. But that is  even more 
later, maybe with R3 when such parts are open.

Hmm, for reads we could 'call wget, at least for reading.

proxy is usually global under OSX, so that should not be hard information 
to get

Have we got 1 Stability and 2 Security yet ? We have jumped to 3 
Proxy, even though everyone agreed to Josh's ordered list.