World: r3wp

Completely different.  I think we discussed www.curl.com on the mailing 
list many years ago.  Someone was saying that they had a proposition 
for View to do a job, but it ended up being done by Curl.

There was discussion way back in 1991 http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlXQTK
about Curl, and the 30Mb download required.

....you mean 2001

Carl: On the test system, we use the proxy named squid version 2.5.9_1 
(http://www.squid-cache.org) under FreeBSD 5.3.

I also tried reading a https page using command and squid, and couldn't 
get it to work.

Altme works throught squid though

Thanks Graham. Good that someone else can recreate the problem.

Is Altme communicating on plain TCP/IP protocol? Does Altme use encryption 
in any way? SSL?

Altme uses encryption but not ssl

I just so happened to have squid setup next to me for another purpose 
...so could easily test.

Out customer Statoil use a hardware proxy from NetApp called NetCache, 
and they have the same problem.
http://www.netapp.com/products/netcache/netcache_family.html

Tunnelling is supported according to their specs: http://www.netapp.com/products/software/software_specs.html

Graham: Do you know, how tunnelling works with squid? (I'm not a 
proxy expert in any way.) Does it have to be turned on or something 
in the config file?

I see the spelling "tunelling" with one 'n' now and then, in case 
you're searching the documentation.

Seems like SSL Tunnelling with squid is on by default on certain 
ports using the CONNECT method:

http://www.squid-cache.org/mail-archive/squid-users/200210/0295.html

Our customer was monitoring the trafik and could see, that nothing 
happened after the CONNECT, so maybe the problem is, that REBOL doesn't 
continue after the CONNECT!? As I understand it, the CONNECT method 
is used to establish a connection between the two computers (client 
and server), and then the proxy simple let the communication continue 
without touching it (allowing SSL encryption and the like). REBOL 
can make the connection, but fail to communicate afterwards. (My 
guess.)

It's interesting, that Altme works using encryption too!? Is the 
CONNECT method in use in this situation?

an encryption tool? I think not ... IMO altme is built upon SSL capability 
of Rebol/Command SDK or even Rebol/Pro? Dunno ...

Pekr: Graham was just saying, that "Altme uses encryption but not 
ssl"

Geomol - there is nothing like "connect". If you have a free bit 
of a free time, I suggest you to download Winpcap and Ethereal - 
they are both free and you get cool network monitoring tool. You 
can learn a lot ...

well, maybe he is right, Graham is clever guy :-)

it may just use normal means of tcp communication with encrypted 
content, using RSA for e.g.

see http://www.rebol.com/docs/encryption.html

Yes

not sure how this discussion started but maybe we are not in correct 
group ...

I started it Tuesday 11:26 with a problem regarding HTTPS over a 
proxy.

ah, proxies ... in our company, although we use Squid IIRC, we have 
following problem - we found out, our admins use kind of load balancing, 
but they are not able to solve session afinity right now, so eg. 
ICQ disconnects after some time, as it can get packed routed using 
different machine and it imo causes communication to break ...

Graham: I've done Ethereal monitoring with our test proxy, and after 
the "HTTP/1.0 200 Connection established" reply from the proxy, there's 
a line from my computer (running REBOL) to the proxy with the text 
"Continuation or non-HTTP traffic". After that, the proxy reply with 
a [FIN, ACK]. If that "continuation" holds the information from my 
REBOL application to go to the server in the other end, it may be 
a proxy problem!?

I notice a bug in the CONNECT request from REBOL to the proxy. Ethereal 
reports:

[Dissector bug, protocol HTTP: "Request Version" - "http.request.version" 
invalid length: -32 (proto.c:2104)]
!?

I'm having some problems with the rebol example webserv.r   I've 
installed it on a computer at home and a computer here at work. It 
works fine at home, but here there appears to be problems with the 
path of the script. The log file is places several places (where 
the webserv.r script is located and severel places inside the www 
path), and there are problems accessing rebol scripts inside :[  
]: - apparently also because of problems with the path. Very wierd 
behaviour. Any help appriciated.

I've solved the problem with HTTPS thru a proxy. The problem is, 
that the commands to the proxy is sent with only a newline in the 
end of each line. If I replace the newlines with carriage-return 
newline ("^M^/"), it works. Within the SDK, the problem is in the 
file "source/prot-http.r".

Geomol, that sounds excellent. Does it still work at home ?

Sorry Geomol, I've mixed your post with Flemming's. Must be time 
to go to sleep :)

Flemming, are you using the same version of rebol and are they on 
the same platform at home as at work ?

Geomol, that is a known bug in ssl, see RAMBO #3532, it is interesting 
to know that it affects HTTPS with proxy

Geomol, can you post the corrected version of prot-http.r somewhere?

Perhaps on the REP site ?

Or, Rebol.org ...

Off topic here, but what do you have to do to create an external 
link on  a web page so that a new browser instance loads. Do you 
need some javascript on the page?

just add target="_blank" in the <a> tag

<a href=http://www.rebol.comtarget=_blank>Rebol</a>  ?

correct

Great!

once second - the quotes aren't there.

targe="_blank"

is that the same for the action of a form ?

hmmm..

Apparently so.

it should if the action is redirection to another page using the 
<a> tag.  But I'd need to look it up to be certain.

Yes, it works :)

It does in Opera, at least.

Including 'post' forms.