Re: [twsocket] Setting additional Header fields depending on the mimetype in th

2011-12-14 Thread Angus Robertson - Magenta Systems Ltd
The implementation should be delegated to a handling class which could be replaced easily by the developper. Yes, it will be a new class in the OverbyteIcsMimeUtils unit. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto

Re: [twsocket] Setting additional Header fields depending on the mimetype in th

2011-12-13 Thread Angus Robertson - Magenta Systems Ltd
Persistant headers are not usefull cause only certain Mimetype need special headers And I believe this is not just a special scenario for our apps. According to Pagespeed and feedback from our users this relative simple change (Date and Expire headers) improved the response times I'm

Re: [twsocket] Setting additional Header fields depending on the mimetype in th

2011-12-13 Thread RTT
On 13-12-2011 08:31, Angus Robertson - Magenta Systems Ltd wrote: I'm just about to change to HttpServer MIME handling again, to use a look-up list read from the Windows classes registry or a text file) when the server starts, to replace the current hard coded MIME list. If filling from the

Re: [twsocket] Setting additional Header fields depending on the mimetype in th

2011-12-13 Thread Angus Robertson - Magenta Systems Ltd
If filling from the registry, better if the list is filled dynamically when a not yet resolved file extension is requested. Except that scanning a single registry node or file, allocating memory for those nodes, and building indexes for them may be more efficient in one function. We don't

Re: [twsocket] Setting additional Header fields depending on the mimetype in th

2011-12-13 Thread François Piette
I'm just about to change to HttpServer MIME handling again, to use a look-up list read from the Windows classes registry or a text file) when the server starts, to replace the current hard coded MIME list. It will be editable by the application. The implementation should be delegated to a