Re: [twsocket] GpHTTPProxy doesn't work correctly
I'm already on line with Stanislav. He made some changes to my old proxy
unit (I sent him a latest non-public revision - under NDA so don't ask him
for it, please) and he merged most of the changes. The result is not working
yet, as I haven't yet have time to look at the merged version...
Primoz
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Francois PIETTE
Sent: Sunday, September 28, 2008 10:02 AM
To: ICS support mailing
Subject: Re: [twsocket] GpHTTPProxy doesn't work correctly
I would suggest you contact Primoz which seem to not read the mailing
list
curently.
His email is primoz at gabrijelcic dot org
--
[EMAIL PROTECTED]
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
- Original Message -
From: Stéphane CHADEYRON [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Saturday, September 27, 2008 11:41 PM
Subject: Re: [twsocket] GpHTTPProxy doesn't work correctly
Hi,
I tried the code of Primoz, but without succes.
I think that it is notably because my GPHTTPPROXY.PAS is not adapted
and
some functions misses me.
Problem is that there is 1 years, I had a programme using this proxy.
Is necessary me put him in the garbage can, or think of you that it is
repairable avec my level (low :P)?
Best regards
STéphane
- Original Message -
From: S.Korotky [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Monday, September 22, 2008 10:34 AM
Subject: Re: [twsocket] GpHTTPProxy doesn't work correctly
Hello, Primoz!
I think the modified code can not solve the problem on its own, without
further
modifications. The reason for this is that ProcessHeader procedure is
called
from
ReceivedFromClient if and only if Client.GotHeader is false, but it is
set
to
true after the very first invocation of the ProcessHeader, so it will
not be
called for all subsequent requests in a given connection.
Best wishes,
Stanislav Korotky.
- Original Message -
From: Primož Gabrijelčič [EMAIL PROTECTED]
To: 'ICS support mailing' twsocket@elists.org
Sent: Monday, September 22, 2008 10:06 AM
Subject: Re: [twsocket] GpHTTPProxy doesn't work correctly
Oh, it is that bug :((
Sorry for not including in the debate sooner, but I lost contact with
GpHttpProxy years ago when I started to work on a custom version for
one of
my customers. Now I had no idea which of the problems I fixed years ago
this
was (yes, I was not using source control at the time :( ).
The trick was to destroy remote socket and recreate it if host or port
changed.
I think this are the two most important parts:
procedure TGpHttpProxy.ProcessHeader(Client: TGpHttpProxyClient);
var
ahost: string;
aport: string;
header : string;
returnContent: string;
resetSocket : boolean;
begin
resetSocket := false;
returnContent := '';
header := Client.Received;
if SameText(FirstEl(header,' ',-1),'CONNECT') then begin
// TCP Tunnel proxy request
HttpData(Client).ProxyType := ptTCPTunnel;
if not IPSec.IsAllowed(Client.PeerAddr) then
returnContent := Response.sTCPTunnelIPForbidden.Text
else if not (ptTCPTunnel in EnabledTypes) then
returnContent := Response.sTCPTunnelClosed.Text
else if not
ProcessTCPTunnelHeader(Client,header,ahost,aport,returnContent) then
returnContent := Response.sTCPTunnelBadRequest.Text;
end
else begin
// HTTP proxy request
HttpData(Client).ProxyType := ptHTTP;
if not IPSec.IsAllowed(Client.PeerAddr) then
returnContent := Response.sHTTPIPForbidden.Text
else if not (ptHTTP in EnabledTypes) then
returnContent := Response.sHTTPClosed.Text
else if not
ProcessHTTPHeader(Client,header,ahost,aport,returnContent,resetSocket)
then
returnContent := Response.sHTTPBadRequest.Text;
end; //else SameText()
// Header parsed, create remote socket.
if returnContent = '' then begin
if resetSocket then begin
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Destroyed connection to %s:%s due to host/port
change',
[Client.RemoteHost, Client.RemoteSocket.Port]);
{$ENDIF LogHttpFlow}
Client.DestroyRemoteSocket;
Client.NumRequests := 1;
end;
if not assigned(Client.RemoteSocket) then with Client do begin
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Opening connection to %s:%s', [ahost, aport]);
{$ENDIF LogHttpFlow}
CreateRemoteSocket;
RemoteHost:= ahost;
RemoteSocket.Port := aport;
RemoteSocket.LineMode := false;
HookRemoteEvents(RemoteSocket);
RemoteSocket.DnsLookup(ahost);
DoRemoteSocketPrepared(Client);
end //with/if
else begin
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Reusing connection to %s:%s
Re: [twsocket] GpHTTPProxy doesn't work correctly
Oh, it is that bug :((
Sorry for not including in the debate sooner, but I lost contact with
GpHttpProxy years ago when I started to work on a custom version for one of
my customers. Now I had no idea which of the problems I fixed years ago this
was (yes, I was not using source control at the time :( ).
The trick was to destroy remote socket and recreate it if host or port
changed.
I think this are the two most important parts:
procedure TGpHttpProxy.ProcessHeader(Client: TGpHttpProxyClient);
var
ahost: string;
aport: string;
header : string;
returnContent: string;
resetSocket : boolean;
begin
resetSocket := false;
returnContent := '';
header := Client.Received;
if SameText(FirstEl(header,' ',-1),'CONNECT') then begin
// TCP Tunnel proxy request
HttpData(Client).ProxyType := ptTCPTunnel;
if not IPSec.IsAllowed(Client.PeerAddr) then
returnContent := Response.sTCPTunnelIPForbidden.Text
else if not (ptTCPTunnel in EnabledTypes) then
returnContent := Response.sTCPTunnelClosed.Text
else if not
ProcessTCPTunnelHeader(Client,header,ahost,aport,returnContent) then
returnContent := Response.sTCPTunnelBadRequest.Text;
end
else begin
// HTTP proxy request
HttpData(Client).ProxyType := ptHTTP;
if not IPSec.IsAllowed(Client.PeerAddr) then
returnContent := Response.sHTTPIPForbidden.Text
else if not (ptHTTP in EnabledTypes) then
returnContent := Response.sHTTPClosed.Text
else if not
ProcessHTTPHeader(Client,header,ahost,aport,returnContent,resetSocket) then
returnContent := Response.sHTTPBadRequest.Text;
end; //else SameText()
// Header parsed, create remote socket.
if returnContent = '' then begin
if resetSocket then begin
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Destroyed connection to %s:%s due to host/port
change',
[Client.RemoteHost, Client.RemoteSocket.Port]);
{$ENDIF LogHttpFlow}
Client.DestroyRemoteSocket;
Client.NumRequests := 1;
end;
if not assigned(Client.RemoteSocket) then with Client do begin
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Opening connection to %s:%s', [ahost, aport]);
{$ENDIF LogHttpFlow}
CreateRemoteSocket;
RemoteHost:= ahost;
RemoteSocket.Port := aport;
RemoteSocket.LineMode := false;
HookRemoteEvents(RemoteSocket);
RemoteSocket.DnsLookup(ahost);
DoRemoteSocketPrepared(Client);
end //with/if
else begin
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Reusing connection to %s:%s', [Client.RemoteHost,
Client.RemoteSocket.Port]);
{$ENDIF LogHttpFlow}
end;
{$IFDEF LogHttpFlow}
LogFlow(Client, 'Request: %s', [FirstEl(header, #13, -1)]);
{$ENDIF LogHttpFlow}
Client.Received := header;
end
else begin
Client.DestroyRemoteSocket;
Client.RemoteContent := returnContent;
end;
Client.GotHeader := true;
end; { TGpHttpProxy.ProcessHeader }
function TGpHttpProxy.ProcessHTTPHeader(Client: TGpHttpProxyClient; var
header, ahost,
aport, returnContent: string; var socketResetRequired: boolean): boolean;
function MakeUrl(aproto, auser, apass, ahost, aport, apath: string):
string;
begin
Result := aproto;
if Last(Result,1) = ':' then
Result := Result + '//'
else if Last(Result,1) '/' then
Result := Result + '://';
if auser '' then begin
Result := Result + auser;
if apass '' then
Result := Result + ':' + apass;
Result := Result + '@';
end;
Result := Result + ahost;
if (aport '') and (aport '80') then
Result := Result + ':' + aport;
Result := Result + apath;
end; { MakeUrl }
var
apass : string;
apath : string;
aproto: string;
auser : string;
command : string;
hdrHost : string;
ignoreNextHopProxy: boolean;
p1: integer;
p2: integer;
s : string;
url : string;
begin { TGpHttpProxy.ProcessHTTPHeader }
Result := false;
socketResetRequired := false;
// extract url from GET/POST header
s := header;
p1 := Pos(' ',s);
if p1 0 then begin
command := First(s,p1-1);
Delete(s,1,p1);
s := TrimLeft(s);
p2 := Pos(' ',s);
if p2 0 then begin
url := Copy(s,1,p2-1);
ParseURL(url,aproto,auser,apass,ahost,aport,apath);
if aport = '' then
aport := '80';
hdrHost := ExtractHeader(header,'Host');
returnContent := '';
ignoreNextHopProxy := false;
DoClientHeaderAvailable(Client,url,header,aproto,auser,apass,ahost,aport,
apath,hdrHost,ignoreNextHopProxy,returnContent);
if (NextHopHTTP.Address '') and (not ignoreNextHopProxy) and
(returnContent = '') then //replace host information with proxy
begin
Delete(header,p1+1,p2-1);
Re: [twsocket] Typedef TSocket - ICS-oldies
I don't remember what that was all about. Probably pre-D4 stuff?
Primoz [who submitted that change]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Arno Garrels
Sent: Saturday, June 30, 2007 7:44 PM
To: 'ICS support mailing'
Subject: [twsocket] Typedef TSocket - ICS-oldies
Hi ICS-oldies,
Do you remember this change in (OverbyteIcs)WSocket.pas ?
May 20, 2000 V4.17 Made TSocket = u_int (same def as in winsock.pas)
..
Thanks to Primoz Gabrijelcic [EMAIL PROTECTED]
interface
..
type
..
{$IFDEF DELPHI4_UP}
{ TSocket type definition has been removed starting from Delphi 4 }
TSocket = u_int;
{$ENDIF}
I may be missing something, however TSocket is defined in my
D4-WinSock.pas as u_int as it is in D7 thru D2007, so I do not
understand why we need to define it once more ?
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] ICS v5 compatibility / WndProc handling
Sure. I'm fine with that. Primoz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arno Garrels Sent: Sunday, June 03, 2007 9:36 AM To: ICS support mailing Subject: Re: [twsocket] ICS v5 compatibility / WndProc handling Primož Gabrijelcic wrote: if assigned(OnMessage) then //Gp OnMessage(Self, MsgRec); //Gp if Result = 0 then //Gp Result := DefWindowProc(Handle, Msg, wParam, lParam); In order to allow zero-results the new event required another boolean var parameter, also note the slightly different name (ICS coding style): -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS v5 compatibility / WndProc handling
Can you please also translate the // On a une superbe fenętre. Dans les informations associées, enregistre la // référence ŕ notre objet. Elle permettra plus tard d'invoquer la // méthode WndProc de gestion des messages envoyés ŕ la fenętre in TIcsWndHandler.AllocateHWnd? I tried to understand it with a little help from the Babelfish, but its translation was less than satisfactory. Best regards, Primoz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois PIETTE Sent: Sunday, June 03, 2007 10:25 AM To: ICS support mailing Subject: Re: [twsocket] ICS v5 compatibility / WndProc handling My vote is pro, depends on Francois, he's the (busy) boss ;-) OK. Also update the comment in french: // Les exceptions doivent etre gérées, sinon l'application sera // liquidée des qu'une exception se produit ! // All exceptions must be handled otherwise the application // will terminate as soon as an exception is raised. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, June 02, 2007 8:19 PM Subject: Re: [twsocket] ICS v5 compatibility / WndProc handling Primož Gabrijelcic wrote: It works fine in our applications. My vote is pro, depends on Francois, he's the (busy) boss ;-) Primoz -Original Message- From: [EMAIL PROTECTED] [mailto:twsocket- [EMAIL PROTECTED] On Behalf Of Arno Garrels Sent: Saturday, June 02, 2007 8:08 PM To: ICS support mailing Subject: Re: [twsocket] ICS v5 compatibility / WndProc handling Looks usefull, though not tested yet. Francois, what do you think? Primož Gabrijelcic wrote: Hello everybody (and especially Francois). I have this legacy code that was written using ICS v5. Deep inside some message processing (specifically RAS handling) is done in overridden WndProc methods. When I switched to ICS v6, this code broke. This was mainly expected - ICS v6 cannot know which socket's WndProc it should call when it receives some non-internal (not registered via AllocateMsgHandler) message after all. Still, I had to make old code work with the new message dispatch system and that's what I did: I defined new event handler in the TIcsWndHandler: TIcsOnMessageEvent = procedure(Sender: TObject; var MsgRec: TMessage) of object; //Gp TIcsWndHandler = class(TObject) FOnMessage : TIcsOnMessageEvent; ... property OnMessage: TIcsOnMessageEvent read FOnMessage write FOnMessage; //Gp In the TIcsWndHandler.WndProc, I call OnMessage if specified: procedure TIcsWndHandler.WndProc(var MsgRec: TMessage); var Dummy : Boolean; begin try with MsgRec do begin if (Msg = FMsgLow) and (Msg (FMsgLow + WH_MAX_MSG)) and Assigned(FMsgMap[Msg - FMsgLow]) then FMsgMap[Msg - FMsgLow].WndProc(MsgRec) else begin if assigned(OnMessage) then //Gp OnMessage(Self, MsgRec); //Gp if Result = 0 then //Gp Result := DefWindowProc(Handle, Msg, wParam, lParam); end; end; except // Les exceptions doivent etre gérées, sinon l'application sera // liquidée dcs qu'une exception se produit ! on E:Exception do TriggerBgException(E, Dummy); end; end; This way, I can catch all messages received by the TIcsWndHandler and call appropriate legacy code inside my OnMessage handler. I think this is a simple extension that adds much flexibility and that I should be included in the base code. What do others think? Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS v5 compatibility / WndProc handling
It works fine in our applications. Primoz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arno Garrels Sent: Saturday, June 02, 2007 8:08 PM To: ICS support mailing Subject: Re: [twsocket] ICS v5 compatibility / WndProc handling Looks usefull, though not tested yet. Francois, what do you think? Primož Gabrijelcic wrote: Hello everybody (and especially Francois). I have this legacy code that was written using ICS v5. Deep inside some message processing (specifically RAS handling) is done in overridden WndProc methods. When I switched to ICS v6, this code broke. This was mainly expected - ICS v6 cannot know which socket's WndProc it should call when it receives some non-internal (not registered via AllocateMsgHandler) message after all. Still, I had to make old code work with the new message dispatch system and that's what I did: I defined new event handler in the TIcsWndHandler: TIcsOnMessageEvent = procedure(Sender: TObject; var MsgRec: TMessage) of object; //Gp TIcsWndHandler = class(TObject) FOnMessage : TIcsOnMessageEvent; ... property OnMessage: TIcsOnMessageEvent read FOnMessage write FOnMessage; //Gp In the TIcsWndHandler.WndProc, I call OnMessage if specified: procedure TIcsWndHandler.WndProc(var MsgRec: TMessage); var Dummy : Boolean; begin try with MsgRec do begin if (Msg = FMsgLow) and (Msg (FMsgLow + WH_MAX_MSG)) and Assigned(FMsgMap[Msg - FMsgLow]) then FMsgMap[Msg - FMsgLow].WndProc(MsgRec) else begin if assigned(OnMessage) then //Gp OnMessage(Self, MsgRec); //Gp if Result = 0 then //Gp Result := DefWindowProc(Handle, Msg, wParam, lParam); end; end; except // Les exceptions doivent etre gérées, sinon l'application sera // liquidée dcs qu'une exception se produit ! on E:Exception do TriggerBgException(E, Dummy); end; end; This way, I can catch all messages received by the TIcsWndHandler and call appropriate legacy code inside my OnMessage handler. I think this is a simple extension that adds much flexibility and that I should be included in the base code. What do others think? Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] ICS v5 compatibility / WndProc handling
Hello everybody (and especially Francois). I have this legacy code that was written using ICS v5. Deep inside some message processing (specifically RAS handling) is done in overridden WndProc methods. When I switched to ICS v6, this code broke. This was mainly expected - ICS v6 cannot know which socket's WndProc it should call when it receives some non-internal (not registered via AllocateMsgHandler) message after all. Still, I had to make old code work with the new message dispatch system and that's what I did: I defined new event handler in the TIcsWndHandler: TIcsOnMessageEvent = procedure(Sender: TObject; var MsgRec: TMessage) of object; //Gp TIcsWndHandler = class(TObject) FOnMessage : TIcsOnMessageEvent; ... property OnMessage: TIcsOnMessageEvent read FOnMessage write FOnMessage; //Gp In the TIcsWndHandler.WndProc, I call OnMessage if specified: procedure TIcsWndHandler.WndProc(var MsgRec: TMessage); var Dummy : Boolean; begin try with MsgRec do begin if (Msg = FMsgLow) and (Msg (FMsgLow + WH_MAX_MSG)) and Assigned(FMsgMap[Msg - FMsgLow]) then FMsgMap[Msg - FMsgLow].WndProc(MsgRec) else begin if assigned(OnMessage) then //Gp OnMessage(Self, MsgRec); //Gp if Result = 0 then //Gp Result := DefWindowProc(Handle, Msg, wParam, lParam); end; end; except // Les exceptions doivent ętre gérées, sinon l'application sera // liquidée dčs qu'une exception se produit ! on E:Exception do TriggerBgException(E, Dummy); end; end; This way, I can catch all messages received by the TIcsWndHandler and call appropriate legacy code inside my OnMessage handler. I think this is a simple extension that adds much flexibility and that I should be included in the base code. What do others think? Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpSrv closing HTTP/1.1 connections without Connection header
Francois, any comments on that? Can you include the fix in the official sources? Primoz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fastream Technologies Sent: Tuesday, May 15, 2007 2:36 PM To: ICS support mailing Subject: Re: [twsocket] HttpSrv closing HTTP/1.1 connections without Connection header Yes I changed that part in our descendent class as well. I did not notice it contained a RFC-break--I just thought it would be better this way, so did not report it. Best Regards, SZ On 5/15/07, Primož Gabrijelčič [EMAIL PROTECTED] wrote: What would happen with your code if the version is HTTP/0.9? These are clients written before the HTTP1.0 RFC! I think you need to parse the exact version number and also consider the future versions as well: Exactly because of future versions I was testing against '1.0' and not '1.1'. I don't believe there are any HTTP/0.9 clients to be found in the real world. Are they? Still, HttpSrv is full of '1.0' and '1.1' tests and does not really 'upgrade' nicely to future HTTP protocols so it would be equally good to write the test as if FVersion = 'HTTP/1.1' then FKeepAlive := true; BTW, so you do agree that this is a bug? Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] HttpSrv closing HTTP/1.1 connections without Connection header
Hello, everybody. Does anybody know why does HttpSrv (1.41, ICS v5) default to closing connection when client sends HTTP/1.1 request without a Connection: header? IOW, when THttpServer receives GET / HTTP/1.1 it will close the connection after sending the response. If one adds 'Connection: keep-alive' to the request header, connection will stay open. This is a proper behaviour for HTTP/1.0 connections but I believe it is in violation of RFC 2616, which states: 8.1.2 Overall Operation A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server. I suggest adding two lines to the very end of the THttpConnection.ParseRequest: if FVersion = '' then FVersion := 'HTTP/1.0'; if FVersion 'HTTP/1.0' then //Gp, 2007-05-15 FKeepAlive := true; //Gp, 2007-05-15 end; Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpSrv closing HTTP/1.1 connections without Connection header
What would happen with your code if the version is HTTP/0.9? These are clients written before the HTTP1.0 RFC! I think you need to parse the exact version number and also consider the future versions as well: Exactly because of future versions I was testing against '1.0' and not '1.1'. I don't believe there are any HTTP/0.9 clients to be found in the real world. Are they? Still, HttpSrv is full of '1.0' and '1.1' tests and does not really 'upgrade' nicely to future HTTP protocols so it would be equally good to write the test as if FVersion = 'HTTP/1.1' then FKeepAlive := true; BTW, so you do agree that this is a bug? Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS threaded server and load balancing
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois Piette This si not a winsock or TCP/IP component issue. It is an OS issue. I don't know Windows has an API to force a thread to run on a given CPU. SetThreadAffinityMask You have an API to know the number of processors. GetProcessAffinityMask Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug report for HTTPProt.pas Line 2644
An usual practice in the RFC world is to be very strict when sending data and very forgiving when receiving. I always code such tests as 'if SameText(..., ...)'. I would support this fix, too. Primoz Hum... is this really a bug or is it Abyss server that is not RFC compliant with a small c ? FT It should be FT else if Field = 'transfer-encoding' then FT FTransferEncoding := LowerCase(Data) FT Not, FT else if Field = 'transfer-encoding' then FT FTransferEncoding := Data FT as for example Abyss web server returns Chunked instead of chunked. FT Best Regards, FT SZ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] listening on a multihomed computer
Hello everybody, I have a following situation. Customer has a multihomed computer (let's say with three public IP addresses) and wants my ICS-based server to bind to only _two_ of those addresses. Is there a way to do that in ICS? If not, is this a limitation of ICS or WinSock? The closest I have come to the answer by myself is to call WSocket_getsockname(Client.HSocket, name, namelen) in OnClientConnect and drop the connection if it comes in on a wrong interface. A better way would be not to listen on wrong interface at all, of course. (Yes, I know I can set up two servers and have each listen on one interface only but that's not the way I would like to go - too many changes in an already convoluted program.) Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] listening on a multihomed computer
Thanks. Primoz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fastream Technologies Sent: Wednesday, February 01, 2006 9:27 AM To: ICS support mailing Subject: Re: [twsocket] listening on a multihomed computer Hi, You can listen on either one of all adapters (0.0.0.0). This is Winsock design. Regards, SZ - Original Message - From: Primoz Gabrijelcic [EMAIL PROTECTED] To: twsocket@elists.org Sent: Wednesday, February 01, 2006 10:17 AM Subject: [twsocket] listening on a multihomed computer Hello everybody, I have a following situation. Customer has a multihomed computer (let's say with three public IP addresses) and wants my ICS-based server to bind to only _two_ of those addresses. Is there a way to do that in ICS? If not, is this a limitation of ICS or WinSock? The closest I have come to the answer by myself is to call WSocket_getsockname(Client.HSocket, name, namelen) in OnClientConnect and drop the connection if it comes in on a wrong interface. A better way would be not to listen on wrong interface at all, of course. (Yes, I know I can set up two servers and have each listen on one interface only but that's not the way I would like to go - too many changes in an already convoluted program.) Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS-V6 files and classes naming
All in all I wonder if it is not better to simply make V6 as compatible as possible with V5. That is dropping support for old compilers (this would make the source code much cleaner) and adding new features without breaking existing ones. If I do that, current ICS user would have no change at all or - if they use an old compiler - just upgrade to the current Delphi or CBuilder compiler (The old compilers would not compile new features using recent language construction). If there is no scenario where V5 ICS works better than V6 ICS then I would like to see V6 as a 'drop in' replacement for V5 - as ICS was managed until now. As for the compiler support, I personally need only D7 and D2006. Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
RE: [twsocket] Is there a way to download a file in threads?
Well, async cannot take advantage of multi-processor systems. Also for CGI and ISAPI execution, threads seem to be a better way. And all the commercial Web servers I know such as IIS and Apache chose it for these reasons. You are mixing up two factors. Even on multi-processor system, one CPU is usually enough to handle connections. That doesn't prevent you from creating additional threads to process CGI and ISAPI requests - nobody says that such requests must execute in the context of the thread handling socket connections. One of my commercial designs is using this approach and it is working just great. Best regards, Primoz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
