libqt-addon removed

[Thiago Macieira]

Dawit A. wrote:
>In order to do that one would need to parse HTTP header, no ? Is it
> wise to do such things in low level networking classes ? IMHO these
> new Socket classes should do only provide the base infrastructure
> needed to deal with say creating a proxied or tunneled (https
> proxying) much like what the TCPSlaveBase class does for SSL support.
> The ability to decipher the proxy server replies should be left up
> the other appropriate handler, in this case the HTTP io-slave.
> Otherwise you start delinating the line between low level networking
> classes and higher level protocol handler implementations.

The support I am talking about here is to offer generic proxying. The 
most common all-purpose proxy protocol is SOCKS5 and we already have 
that implemented in KSocks, through loading of an external library.

So, KDE code when running behind such a proxy can still make outgoing 
connections (incoming as well).

However, more and more do companies only use HTTP proxies now. The idea 
behind this is to support a generic connection through HTTP, via the 
CONNECT command. So, yes, it does parse the server reply header: if it 
sees a 2xx reply, the connection established; if it sees 4xx or 5xx, 
the connection did not establish -- including the 401 Authorization 
Required reply. 

And this works only for outgoing connections.

>Also as the person who has spent a lot of time working on the current
> proxy support in KDE, I can tell you that eventhough some of the
> proxying stuff does really belongs in low level networking classes,
> there are many challanges in incorporating that stuff in there.
> Anyways, I will reserve my remaining $0.01 until after I see the
> proxy support in the new classes. :)

You are talking about the proxying in kio_http. That's fine on itself, 
because HTTP proxies were made for HTTP. This code is similar to HTTPS 
connections through a HTTP proxy.

I think that I will provide a simple method for setting the username and 
password to send to the proxy server and allow the answer code (maybe 
the full headers?) to be retrieved. That way, an application or a 
higher level handler may choose to do something about a connection 
failure -- under no circumstances will the code contain the creation of 
a window to request a new password: that's not my job.

This feature has been requested mainly by Kopete developers, who want to 
be able to make their connections through a HTTP proxy (you see other 
IM clients do that). I have promised them to code like this:

KStreamSocket socket(host, port);
socket.setSocketDevice(new KHttpProxySocketDevice(proxyhost,proxyport));
if (!socket.connect())
  /* failure connecting */

PS: this _does_ already work 
-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040514/c7d8d6c9/attachment.sig>