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

2010-09-11 Thread Arno Garrels
RTT wrote: Done. I've now sent you a PM with the .diff file. Thanks. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be

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

2010-09-11 Thread Angus Robertson - Magenta Systems Ltd
But, why don't keep the naming schema? TriggerAfterProcessRequest ( and respective OnAfterProcessRequest) would be less confuse. The event is between two processing stages, so could be named after one or before the other. What is the purpose of the OPTIONS method? Angus -- To unsubscribe

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

[twsocket] THttpServer - How to handle unimplemented request methods

2010-09-09 Thread RTT
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