so i managed to disabled track session by IP by editing idCustomHTTPServer
You edited the implementation of the TIdHTTPDefaultSessionList class, which is used only when you DON'T provide a custom class to replace it. So why didn't you simply derive a new class from TIdHTTPCustomSessionList, like I suggested earlier? Then you could have overridden the GetSession() to ignore the RemoteIP parameter, and not have to edit Indy itself at all. For example:
type
TMyHTTPSessionList = class(TIdHTTPDefaultSessionList)
public
function GetSession(const SessionID, RemoteIP: string): TIdHTTPSession; override;
end;
function TMyHTTPSessionList.GetSession(const SessionID, RemoteIP: string): TIdHTTPSession;
begin
Result := inherited GetSession(SessionID, '');
end;
...
IdHTTPServer1.SessionList := TMyHTTPSessionList.Create(IdHTTPServer1);
IdHTTPServer1.Active := True;
i know its not the best practice, but i need fast solution back there..
It would have been faster and easier to write a custom class directly in your project code and assign it to TIdHTTPServer, rather than editing, recompiling, and reinstalling Indy itself.
but there's another problem, when a GET request attempt from client the httpCommandGet method firing repeatedly like 4 or 5 times, so in what scenario did this happen?
I can't answer that without seeing the client's traffic. Obviously it is making multiple requests to your server. You will have to look at the details of each request to see exactly what it is really requesting.
ok so i did a little research this is my code :
aresponseinfo.ContentType:='application/pdf';
aresponseinfo.ContentDisposition:='attachment; filename="' + get_nip_from_id(arequestinfo.Params.Values['p']) + '.pdf"';
aresponseinfo.ContentStream:=generate_report(arequestinfo.Params.Values['p']);
aresponseinfo.WriteContent;
aresponseinfo.ContentStream:=nil;
You don't need the last 2 lines (especially since the last one is causing a memory leak). Simply assign the ContentStream and then exit the OnCommandGet event handler. TIdHTTPServer will then transmit the data for you, and free the stream when finished.
if i comment "//" contentdisposition it went okay... but my response to client will be different from what i expected.
The Content-Disposition header (or lack of one) will not cause the client to send multiple requests. Something else is going on.