Re: [twsocket] THttpServer POST

2010-09-10 Thread David Lewis
I've looked at the demo, which got me to come up with the following code, however it doesn't work yet. I get the PostDocument event, but it doesn't appear to progress to the PostedData event (I don't get any PostedData logs) Any thoughts that may fix me? // Extract from setup: #define

[twsocket] GBs of Memory leak which Memproof says is at the line Send(FDocBuf, len);

2010-09-10 Thread Fastream Technologies
Hello, I have downloaded today's snapshot and when under high bandwidth traffic, the buffering seems to leak memory until I delete the THttpConnection descendents. Could somebody take a look at OverbyteWSockBuf unit? Regards, SZ -- To unsubscribe or change your settings for TWSocket mailing

Re: [twsocket] GBs of Memory leak which Memproof says is at the line Send(FDocBuf, len);

2010-09-10 Thread Fastream Technologies
Let me elaborate: As our code is a proxy server and data keeps coming down in OnDocData of the Httpclient, I was pumping it to THttpConnection's descendent with Send(buf, len). However I noticed it was actually buffering data when the Send()'s pace is less than Receive(). So it might be a special

Re: [twsocket] GBs of Memory leak which Memproof says is at the line Send(FDocBuf, len);

2010-09-10 Thread Fastream Technologies
Hello again, I have found out that there are two linked lists in wsockbuf: inuse and free. And even the allocated memory in free is not freed in some cases. It must have been intended for reusing but it is no good to keep hundreds of MBs of unused buffers in memory! There must be a limit to the

Re: [twsocket] GBs of Memory leak which Memproof says is at the line Send(FDocBuf, len)

2010-09-10 Thread Arno Garrels
Fastream Technologies wrote: Let me elaborate: As our code is a proxy server and data keeps coming down in OnDocData of the Httpclient, I was pumping it to THttpConnection's descendent with Send(buf, len). However I noticed it was actually buffering data when the Send()'s pace is less than

Re: [twsocket] GBs of Memory leak which Memproof says is at the line Send(FDocBuf, len)

2010-09-10 Thread Arno Garrels
Arno Garrels wrote: Fastream Technologies wrote: Let me elaborate: As our code is a proxy server and data keeps coming down in OnDocData of the Httpclient, I was pumping it to THttpConnection's descendent with Send(buf, len). However I noticed it was actually buffering data when the Send()'s

Re: [twsocket] THttpServer POST

2010-09-10 Thread Arno Garrels
David Lewis wrote: I've looked at the demo, which got me to come up with the following code, however it doesn't work yet. I get the PostDocument event, but it doesn't appear to progress to the PostedData event (I don't get any PostedData logs) Any thoughts that may fix me? From a brief

Re: [twsocket] GBs of Memory leak which Memproof says is at the line Send(FDocBuf, len)

2010-09-10 Thread Fastream Technologies
Working like a charm now! Thanks a lot goes to Arno (as usually!). On Fri, Sep 10, 2010 at 5:42 PM, Arno Garrels arno.garr...@gmx.de wrote: Arno Garrels wrote: Fastream Technologies wrote: Let me elaborate: As our code is a proxy server and data keeps coming down in OnDocData of the

Re: [twsocket] THttpServer - How to handle unimplemented request methods

2010-09-10 Thread Arno Garrels
RTT wrote: Hi everyone! Is there any simple way to handle other than the GET, POST and HEADER request methods,... as OPTIONS,...? The way it is now, the THttpConnection.ProcessRequest procedure always respond with a Answer501, not giving any chance to handle other methods. I think a

Re: [twsocket] THttpServer - How to handle unimplemented request methods

2010-09-10 Thread RTT
On 10-09-2010 16:43, Arno Garrels wrote: Another thing that would be useful, if added to the code base of the THttpConnection, is the possibility to send additional headers from the THttpConnection.SendDocument, to define cache control, etc.. procedure

Re: [twsocket] THttpServer - How to handle unimplemented request methods

2010-09-10 Thread Angus Robertson - Magenta Systems Ltd
Is there any simple way to handle other than the GET, POST and HEADER request methods,... as OPTIONS,...? You'd currently have to override the entire ProcessRequest procedure to add a new method. By the way, the TriggerBeforeAnswer is used in what scenarios? From the code above, it

Re: [twsocket] THttpServer - How to handle unimplemented request methods

2010-09-10 Thread Arno Garrels
RTT wrote: On 10-09-2010 16:43, Arno Garrels wrote: Another thing that would be useful, if added to the code base of the THttpConnection, is the possibility to send additional headers from the THttpConnection.SendDocument, to define cache control, etc.. procedure

Re: [twsocket] THttpServer - How to handle unimplemented request methods

2010-09-10 Thread RTT
Thank you for the explanation Angus. But, why don't keep the naming schema? TriggerAfterProcessRequest ( and respective OnAfterProcessRequest) would be less confuse. Rui -- To unsubscribe or change your settings for TWSocket mailing list please goto

Re: [twsocket] THttpServer - How to handle unimplemented request methods

2010-09-10 Thread RTT
Done. I've now sent you a PM with the .diff file. Feel free to apply your changes to the latest SVN revision and send me the patch file by PM. Changes MUST not break existing code and a change log in unit's comment section was helpful too. -- To unsubscribe or change your settings for