Is there a reason you placed the calls in this sequences?
I used that sequence so the main application can check if the MIME type
is correct and then change it, ie just handle exceptions. The default
MIME code is not exactly processor intensive.
why the String parameters are not declared
I also find myself with the need to edit the DocumentToContentType
function, each time I update my local copy of ICS.
SVN has been updated with a new OverbyteIcsHttpSrv:
Oct 21, 2011 V7.41 Angus added OnHttpMimeContentType to allow custom
ContentTypes to be supported for unusual file
On 21-10-2011 19:18, Angus Robertson - Magenta Systems Ltd wrote:
Oct 21, 2011 V7.41 Angus added OnHttpMimeContentType to allow custom
ContentTypes to be supported for unusual file extensions.
Seems to be working, but why the heck you call the internal
DocumentToContentType, even if it is
Oct 21, 2011 V7.41 Angus added OnHttpMimeContentType to allow
custom ContentTypes to be supported for unusual file extensions.
Very nice.
Is there a reason you placed the calls in this sequences? I think
procedure THttpConnection.SendDocument[..]
begin
ErrorSend := FALSE;
I also find myself with the need to edit the DocumentToContentType
function, each time I update my local copy of ICS.
This has not being addressed yet
I get annoyed every time I look at the list of MIME types as well, and
have added to it myself in the past.
I will do something better in
I also find myself with the need to edit the DocumentToContentType
function, each time I update my local copy of ICS.
This has not being addressed yet, so how about if, instead of the more
complex implementation proposed here, an assignable
OnDocumentToContentType property is added to the
Hi,
after getting chewed out (again!) for forgetting to extend the
DocumentToContentType function after an update of ICS, I like to suggest
an improvement.
As base use a THashedStringlist (or something similar).
Fill the list with the default extension/contentType names and values pairs
and
