thiago.macieira at kdemail.net
Fri May 14 14:28:50 BST 2004
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
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);
/* 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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel