You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Bayley <ba...@mac.com> on 2001/08/09 15:38:03 UTC
modifying MIME handling
Hello,
I would like to modify how Apache associates files with MIME Types, but I'm not exactly clear how to implement it without gutting mod_mime.c (which some Apache developers may not like). This document is longer than I would have liked, but if I dived into code examples without some background I wouldn't be too popular.
Generally speaking my goal is to add support for mapping HFS+ file types to MIME types in Apache running on Darwin 1.x. Currently Apache only supports mapping filename extensions (in a case insensitive manner) to MIME types, and also optionally using 'magic' numbers which read the first few bytes of a file to determine it's type. Most OS X users would probably find utility in this change. I wish to implement this in a manner which:
a) Is as flexible if not more so than the current filename extension behavior.
b) Doesn't clutter Apache code with Darwin-specific code (and loads of #ifdef __APPLE__ macros, nobody wants that)
c) Doesn't clutter Apache resource files
d) Doesn't change the current mechanism significantly
e) Doesn't give anybody a reason to disallow it being merged with Apache source.
I have studied the source and documentation off and on for a long time and have arrived at a few stumbling blocks, mainly because I don't know what changes are liable to make others disagreeable. For example there is no effort anywhere to distinguish between filename extensions and other forms of 'type declaration' in the source, config files, database, or directives. It's just implied that, for example, "AddType" means add a filename extension to MIME type mapping entry. I have several thoughtful suggestions how I can add support for another mapping type without causing confusion. As soon as somebody tells me which is preferable, I will likely seek advice how to implement it without gutting current source.
Runtime database:
To implement a new file mapping I can either:
a) Create a new entry, disassociated with mod_mime's current entries. Thus a new entry like forced_types_hfs could be "image/jpeg 'JPEG'".
b) Create a new entry like (a), but also change the filename extension mapping entries to be more specific like forced_filename_extension_mapping_types or forced_types_ext.
c) Use the current entries, but change the syntax so filename extensions and file types are easily distinguished. Thus a forced_types entry could be "image/jpeg jpeg jpg jpe 'JPEG'" where 'JPEG' means file type.
The difficulty in implementation (explained later) is about the same.
Apache Directive Syntax:
The current syntax merely implies filename extension mapping. Even the period prefix which can be used to signify that an entry is a filename extension is optional (like "Addtype image/gif .gif" is the same as "Addtype image/gif gif"). To implement a new file mapping directive syntax I can either:
a) Create a new set of directives, similar to the current ones. For example "AddTypeHFS image/gif 'GIF '"
b) Do the same, and also change the filename extension syntax to me more specific. For example "AddExtensionMimeMapping" or "AddTypeExt"
c) Use the same directive, but change the syntax to allow file type entries like "AddType image/jpeg jpeg jpg jpe 'JPEG'"
One possible problem is a file type isn't limited to 7bit ascii. If this is important (please tell me) I can change the syntax to '0xFFFFFFFF" or "'0xFFFFFFFF". I don't anticipate a problem with upper ascii characters since they will be platform specific anyway (and will have it's own separate config file).
The difficulty in implementation is about the same.
Implementation in source code:
There is no cost in fetching the file type so long you do it while fetching the filename (where is this done?). If you try to fetch a file type when it isn't set, or from a filesystem which doesn't support them it returns null. Thus there is no reason not to always have this option on when running on Darwin. The primary difference between filename extensions and file types is Apache matches filename extensions in a case insensitive manner while file types are any 32bit value (or four char code).
It does this by converting filename extensions to lower case before entering them in the runtime database, then converting the filename extension in question to lower case, then strcmp(). Personally I don't understand why strcasecmp() wasn't used instead, perhaps because it was slightly faster. I don't know many filename extensions which are case dependent (.C vs .c, .Z vs .z) so the option of making it case sensitive given a directive would be rather pointless. Anyway I'm not going to challenge that decision (unless somebody else does) so I'm not going to muck with it.
However it does mean that if I want to use the same database entry for file types, I will have to check if the first character is "'". The currently code does this in several places (which makes me wonder why there isn't a macro):
if (*ext == '.')
++ext;
ap_str_tolower(ct);
so I would have to change the code to something effectively like:
if (*ext == '.')
{
++ext;
ap_str_tolower(ct);
}
else if (*ext != '\'')
else //assume filename extenion
ap_str_tolower(ct);
If this were a macro, the #ifdef __Apple__ would only be in one place instead of every directive function.
If this modification to mod_mime.c were done, I would also want to add a directive to change which mapping had priority. Thus one Darwin user may prefer filename extension mapping, another may prefer file type mapping, and another may want filename extension mapping in one directory only.
If you want me to develop a separate module the priority issue will have to be addressed because load order doesn't allow the user to change the priority on a directory-specific basis.
If you have any suggestions or questions, please go right ahead. I'm partial to using the existing directives with a slightly modified syntax and a modified mod_mime. All existing config files would work as-is and the source will probably be smaller. All I really need to know is what method stands the greatest change of being submitted, where does Apache read the filename, and how to submit the changes.
Thank you for your time. And remember, vote soon and often |-)
Re: modifying MIME handling
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Paul Bayley" <ba...@mac.com>
Sent: Friday, August 10, 2001 12:25 AM
> >The one problem I'd like to see addressed that mod_mime_* mechanisms respect the decisions
> >that are made before, and this becomes a run-all instead of a run-until-success. With now
> >five different aspect to detect (we've got language, content-type, forced handlers, charset
> >and one I'm forgetting), we have to get off the idea that one mod_mime_any module will ever
> >answer all the questions :)
>
> But how does one set module priority per directory?
You don't, nor do you need to.
Your mod_mime_file_attr module would always run first. It's per-dir config would set up the
enabled/disabled flag. In the mime phase, it would simply return declined.
This is the best solution on hfs volumes, so you set it as HOOK_FIRST.
Apache doesn't need a per-dir ordering. It's much more expensive if we make that decision
on every hook chain, then if a module author implements it when it's needed.
Bill
Re: modifying MIME handling
Posted by Paul Bayley <ba...@mac.com>.
>
>First, mod_mime understands filename extensions (and mapping files).
>
>mod_mime_magic understands file contents.
>
>mod_mime_hfs could grok the additional indentification streams on the file :)
The problem there is how do I change which module takes precedence per directory.
>
>I think mixing apples and oranges will cause headaches. Have the user follow mod_mime_hfs,
>then mod_mime (for extensions or file maps), then mod_mime_magic (the last resort.)
If only apples were labeled apples and oranges were labeled oranges. AddType doesn't imply anything about filename extensions, neither does mod_mime.
>
> > One possible problem is a file type isn't limited to 7bit ascii. If this is important (please tell me) I can change the syntax to
>'0xFFFFFFFF" or "'0xFFFFFFFF". I don't anticipate a problem with upper ascii characters since they will be platform specific anyway
>(and will have it's own separate config file).
>
>On WinNT all configs are considered utf-8. On Unix/Win9x the conf file is essentially
>treated as the locally defined code page.
I fail to see what WinNT has to do with anything.
>
> > Implementation in source code:
>> There is no cost in fetching the file type so long you do it while fetching the filename (where is this done?). If you try to
>fetch a file type when it isn't set, or from a filesystem which doesn't support them it returns null.
>
>Please see apr_dir_read and apr_stat/lstat/getfileinfo. The concept is this:
>
> . if the user asks for something, research it (no matter how painful, such as
> the file ownership or permissions on Win32.)
>
> . if an apr_finfo_t field comes for free, fill it in anyways :)
>
> . so on Unix, group/user ids are filled in, even if the user stats for APR_FINFO_MIN.
> Not for Win32, which will quintupple the time required for the stat :(
>
> . on Win32, nearly the entire apr_finfo_t is filled out for apr_dir_read, even when
> asked for APR_FINFO_DIR.
Would anybody complain if I add fields from attr.h?
> > Thus there is no reason not to always have this option on when running on Darwin. The primary difference between filename
>extensions and file types is Apache matches filename extensions in a case insensitive manner while file types are any 32bit value
>(or four char code).
>
>This doesn't map terribly cleanly :( Dunno what we aught to do about it. AS400 and Win32
>also have alternate streams (so do some Mac filesystems, no?) that may encode things like
>the language or charset. It would be nice to find some apr_ methods to extract this useful
>data for Apache.
It would be possible to map ttxt to the mac roman charset but I don't see much demand for it. Everything is unicode these days anyway.
>
>
>> It does this by converting filename extensions to lower case before entering them in the runtime database, then converting the
>filename extension in question to lower case, then strcmp(). Personally I don't understand why strcasecmp() wasn't used instead,
>perhaps because it was slightly faster.
>
>Not if it's tested multiple times :( Once, yes, but when you are comparing against a very
>large table, and indexing via a hash, it's pointless.
I found out that it uses strcasecmp() anyway, but in the table lookup, so I can't use tables. Makes me wonder why everything is tolowered in the first place.
Anyway it's irrelevant now.
> > If this modification to mod_mime.c were done, I would also want to add a directive to change which mapping had priority. Thus one
>Darwin user may prefer filename extension mapping, another may prefer file type mapping, and another may want filename extension
>mapping in one directory only.
>
>Understood, but this can't happen in mod_mime.
Where then?
>
>> If you want me to develop a separate module the priority issue will have to be addressed because load order doesn't allow the user
>to change the priority on a directory-specific basis.
>
>So on a Darwin config, set mod_mime_hfs as the highest priority module. It can have a fast
>escape based on the <Directory > config (even dynamically detected) which drops the file on
>to mod_mime. It can partially fill in the info, and leave other issues (language?) for
>mod_mime or mod_mime magic.
>
>The one problem I'd like to see addressed that mod_mime_* mechanisms respect the decisions
>that are made before, and this becomes a run-all instead of a run-until-success. With now
>five different aspect to detect (we've got language, content-type, forced handlers, charset
>and one I'm forgetting), we have to get off the idea that one mod_mime_any module will ever
>answer all the questions :)
But how does one set module priority per directory?
Re: modifying MIME handling
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Paul Bayley" <ba...@mac.com>
Sent: Thursday, August 09, 2001 8:38 AM
> Hello,
> I would like to modify how Apache associates files with MIME Types, but I'm not exactly clear how to implement it without gutting
mod_mime.c (which some Apache developers may not like). This document is longer than I would have liked, but if I dived into code
examples without some background I wouldn't be too popular.
Please set your text to wrap at column 72 or some such :)
Second, I'm commenting from Apache 2.0. I wouldn't expect the Apache group
to even consider projects of this scope for Apache 1.3. Apache 2.0 offers
so much more versitility, it isn't even worth frustrating yourself over 1.3.
> Generally speaking my goal is to add support for mapping HFS+ file types to MIME types in Apache running on Darwin 1.x. Currently
Apache only supports mapping filename extensions (in a case insensitive manner) to MIME types, and also optionally using 'magic'
numbers which read the first few bytes of a file to determine it's type. Most OS X users would probably find utility in this change.
I wish to implement this in a manner which:
>
> a) Is as flexible if not more so than the current filename extension behavior.
>
> b) Doesn't clutter Apache code with Darwin-specific code (and loads of #ifdef __APPLE__ macros, nobody wants that)
>
> c) Doesn't clutter Apache resource files
>
> d) Doesn't change the current mechanism significantly
>
> e) Doesn't give anybody a reason to disallow it being merged with Apache source.
First, mod_mime understands filename extensions (and mapping files).
mod_mime_magic understands file contents.
mod_mime_hfs could grok the additional indentification streams on the file :)
> I have studied the source and documentation off and on for a long time and have arrived at a few stumbling blocks, mainly because
I don't know what changes are liable to make others disagreeable. For example there is no effort anywhere to distinguish between
filename extensions and other forms of 'type declaration' in the source, config files, database, or directives. It's just implied
that, for example, "AddType" means add a filename extension to MIME type mapping entry. I have several thoughtful suggestions how I
can add support for another mapping type without causing confusion. As soon as somebody tells me which is preferable, I will likely
seek advice how to implement it without gutting current source.
>
> Runtime database:
> To implement a new file mapping I can either:
>
> a) Create a new entry, disassociated with mod_mime's current entries. Thus a new entry like forced_types_hfs could be "image/jpeg
'JPEG'".
>
> b) Create a new entry like (a), but also change the filename extension mapping entries to be more specific like
forced_filename_extension_mapping_types or forced_types_ext.
>
> c) Use the current entries, but change the syntax so filename extensions and file types are easily distinguished. Thus a
forced_types entry could be "image/jpeg jpeg jpg jpe 'JPEG'" where 'JPEG' means file type.
>
> The difficulty in implementation (explained later) is about the same.
I think mixing apples and oranges will cause headaches. Have the user follow mod_mime_hfs,
then mod_mime (for extensions or file maps), then mod_mime_magic (the last resort.)
> Apache Directive Syntax:
> The current syntax merely implies filename extension mapping. Even the period prefix which can be used to signify that an entry is
a filename extension is optional (like "Addtype image/gif .gif" is the same as "Addtype image/gif gif"). To implement a new file
mapping directive syntax I can either:
>
> a) Create a new set of directives, similar to the current ones. For example "AddTypeHFS image/gif 'GIF '"
>
> b) Do the same, and also change the filename extension syntax to me more specific. For example "AddExtensionMimeMapping" or
"AddTypeExt"
>
> c) Use the same directive, but change the syntax to allow file type entries like "AddType image/jpeg jpeg jpg jpe 'JPEG'"
>
> One possible problem is a file type isn't limited to 7bit ascii. If this is important (please tell me) I can change the syntax to
'0xFFFFFFFF" or "'0xFFFFFFFF". I don't anticipate a problem with upper ascii characters since they will be platform specific anyway
(and will have it's own separate config file).
On WinNT all configs are considered utf-8. On Unix/Win9x the conf file is essentially
treated as the locally defined code page.
> The difficulty in implementation is about the same.
>
> Implementation in source code:
> There is no cost in fetching the file type so long you do it while fetching the filename (where is this done?). If you try to
fetch a file type when it isn't set, or from a filesystem which doesn't support them it returns null.
Please see apr_dir_read and apr_stat/lstat/getfileinfo. The concept is this:
. if the user asks for something, research it (no matter how painful, such as
the file ownership or permissions on Win32.)
. if an apr_finfo_t field comes for free, fill it in anyways :)
. so on Unix, group/user ids are filled in, even if the user stats for APR_FINFO_MIN.
Not for Win32, which will quintupple the time required for the stat :(
. on Win32, nearly the entire apr_finfo_t is filled out for apr_dir_read, even when
asked for APR_FINFO_DIR.
> Thus there is no reason not to always have this option on when running on Darwin. The primary difference between filename
extensions and file types is Apache matches filename extensions in a case insensitive manner while file types are any 32bit value
(or four char code).
This doesn't map terribly cleanly :( Dunno what we aught to do about it. AS400 and Win32
also have alternate streams (so do some Mac filesystems, no?) that may encode things like
the language or charset. It would be nice to find some apr_ methods to extract this useful
data for Apache.
> It does this by converting filename extensions to lower case before entering them in the runtime database, then converting the
filename extension in question to lower case, then strcmp(). Personally I don't understand why strcasecmp() wasn't used instead,
perhaps because it was slightly faster.
Not if it's tested multiple times :( Once, yes, but when you are comparing against a very
large table, and indexing via a hash, it's pointless.
> If this modification to mod_mime.c were done, I would also want to add a directive to change which mapping had priority. Thus one
Darwin user may prefer filename extension mapping, another may prefer file type mapping, and another may want filename extension
mapping in one directory only.
Understood, but this can't happen in mod_mime.
> If you want me to develop a separate module the priority issue will have to be addressed because load order doesn't allow the user
to change the priority on a directory-specific basis.
So on a Darwin config, set mod_mime_hfs as the highest priority module. It can have a fast
escape based on the <Directory > config (even dynamically detected) which drops the file on
to mod_mime. It can partially fill in the info, and leave other issues (language?) for
mod_mime or mod_mime magic.
The one problem I'd like to see addressed that mod_mime_* mechanisms respect the decisions
that are made before, and this becomes a run-all instead of a run-until-success. With now
five different aspect to detect (we've got language, content-type, forced handlers, charset
and one I'm forgetting), we have to get off the idea that one mod_mime_any module will ever
answer all the questions :)
> If you have any suggestions or questions, please go right ahead. I'm partial to using the existing directives with a slightly
modified syntax and a modified mod_mime. All existing config files would work as-is and the source will probably be smaller. All I
really need to know is what method stands the greatest change of being submitted, where does Apache read the filename, and how to
submit the changes.
Forget 1.3. Read apr's file_io directory, compare Unix to Win32 and OS2, and start implementing
the Darwin specifics.
Then we can expand apr_finfo_t just a bit to allow some 'extended' info, that will be very
platform specific. Add some accessors to ask the non-http kind of questions (what charset
is this file? what content?) And then implement a new mime module to get this metadata from
the filesystem, in a non-filesystem specific manner :)
Just my 2c
Bill
Re: modifying MIME handling
Posted by Paul Bayley <ba...@mac.com>.
I just found out that ap_table_get is case insensitive.
Now what |-\
Re: modifying MIME handling
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 09 August 2001 22:38, Marc Slemko wrote:
> On Thu, 9 Aug 2001, Ryan Bloom wrote:
> > On Thursday 09 August 2001 22:06, Paul Bayley wrote:
> > > >you can make your module's ap_hook_type_checker get called before
> > > >mod_mime's hook. but I think this is a server-wide setting, not a
> > > >directory setting.
> > >
> > > Is there any way to change the priority per directory?
> >
> > No. It would be a pretty big performance hit to re-order our module
> > lists for every directory.
>
> ...but you can cheat somewhat for the presumably limited requirements
> here.
>
> Have your module consist of two modules using the same code behind
> them. One is added before mod_mime, one after. Then have a config
> directive that lets you set which is actually used for a given
> directory.
>
> Ugly? Inflexible? Single purposed? Sure. A way to do it... maybe.
Yeah, that would work. Actually, you could do this even easier with just one
module. That module would register the same function twice, once before mod_mime,
and once after. Because Apache 2.0 does module ordering per-function, you
don't need to duplicate any code at all. :-)
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: modifying MIME handling
Posted by Marc Slemko <ma...@znep.com>.
On Thu, 9 Aug 2001, Ryan Bloom wrote:
> On Thursday 09 August 2001 22:06, Paul Bayley wrote:
> > >you can make your module's ap_hook_type_checker get called before
> > >mod_mime's hook. but I think this is a server-wide setting, not a
> > >directory setting.
> >
> > Is there any way to change the priority per directory?
>
> No. It would be a pretty big performance hit to re-order our module lists for every
> directory.
...but you can cheat somewhat for the presumably limited requirements
here.
Have your module consist of two modules using the same code behind
them. One is added before mod_mime, one after. Then have a config
directive that lets you set which is actually used for a given
directory.
Ugly? Inflexible? Single purposed? Sure. A way to do it... maybe.
Re: modifying MIME handling
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 09 August 2001 22:06, Paul Bayley wrote:
> >you can make your module's ap_hook_type_checker get called before
> >mod_mime's hook. but I think this is a server-wide setting, not a
> >directory setting.
>
> Is there any way to change the priority per directory?
No. It would be a pretty big performance hit to re-order our module lists for every
directory.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: modifying MIME handling
Posted by Paul Bayley <ba...@mac.com>.
>
>
>you can make your module's ap_hook_type_checker get called before
>mod_mime's hook. but I think this is a server-wide setting, not a
>directory setting.
>
Is there any way to change the priority per directory?
Re: modifying MIME handling
Posted by Ian Holsman <ia...@cnet.com>.
On 09 Aug 2001 12:18:08 -0700, Paul Bayley wrote:
> I think I'm going to have to write a new module from scratch. I can extend mod_mime but it would just change too many things and I'll only end up writing a patch which has zero chance of submission. I'm not looking forward to this.
>
you could do the stuff you want to do, and if your module can't handle
it it cold return DECLINED, and let the normal mod_mime give it a shot
> Question is how would it be possible to change which module has priority in which directory. Is that possible?
you can make your module's ap_hook_type_checker get called before
mod_mime's hook. but I think this is a server-wide setting, not a
directory setting.
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: modifying MIME handling
Posted by Paul Bayley <ba...@mac.com>.
I think I'm going to have to write a new module from scratch. I can extend mod_mime but it would just change too many things and I'll only end up writing a patch which has zero chance of submission. I'm not looking forward to this.
Question is how would it be possible to change which module has priority in which directory. Is that possible?
Re: modifying MIME handling
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Paul Bayley" <ba...@mac.com>
Sent: Thursday, August 09, 2001 10:34 AM
> At 4:03 PM +0200 8/9/01, Carlos Costa Portela wrote:
> >On Thu, 9 Aug 2001, Paul Bayley wrote:
> >
> >> Implementation in source code:
> >> There is no cost in fetching the file type so long you do it
> >> while fetching the filename (where is this done?). If you try to fetch
> >
> > IMHO, it might be too costly to check file types. What's your
> >opinion?
> >
>
> The type information is directly associated with each file like it's creation date or file permissions. It's not in a separate
file, database, or registry. It's cached like all other metadata. The API allows me to fetch only what I want, namely the filename
and type (and whatever else Apache wants to know). Just pass one function the inode and you have it. It's only 32bits.
>
> It would be no more costly than a filename which was four characters longer.
Merging this comment with...
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Thursday, August 09, 2001 7:26 PM
> Forget 1.3. Read apr's file_io directory, compare Unix to Win32 and OS2, and start implementing
> the Darwin specifics.
>
> Then we can expand apr_finfo_t just a bit to allow some 'extended' info, that will be very
> platform specific. Add some accessors to ask the non-http kind of questions (what charset
> is this file? what content?) And then implement a new mime module to get this metadata from
> the filesystem, in a non-filesystem specific manner :)
... this thought, I came up with the following;
if we allow some extended-attribute pointer in the apr_finfo_t itself, palloc'ed the
size of the file name -plus- the bytes required for the 'extra info', and set up the
pointer into this area (after the fname's trailing null?)
It can either be an array of extra info pointers, pointing at the strings, or simple
ea items that look something like
typedef enum apr_finfo_eitype_e {
APR_EXTINFO_LANGUAGE,
APR_EXTINFO_CHARSET,
APR_EXTINFO_MIMETYPE,
... etc
} apr_finfo_eitype_e ;
apr_finfo_ei_t {
apr_finfo_ei_t *next;
apr_finfo_eitype_e type;
char *value;
}
Define what ea's are platform neutral (Language, Content-Type, Charset, etc) and useful
to the rest of the world, consistent with what we've tried doing with apr.
Therefore, we keep a single palloc of the name+info, populate where it is next-to-free,
and add an APR_FINFO_EINFO flag to ask (if it's expensive) what else we can discover
from the filesystem. [This does NOT imply trying to derive info from the file's name!]
Don't know if this appeals, but it is a thought. I'd be happy to start cracking on WinNT
in about two weeks (NTFS supports these sort of constructs, they don't work on FAT/FAT32
volumes or 9x at all.)
Bill
Re: modifying MIME handling
Posted by Paul Bayley <ba...@mac.com>.
At 4:03 PM +0200 8/9/01, Carlos Costa Portela wrote:
>On Thu, 9 Aug 2001, Paul Bayley wrote:
>
>> Implementation in source code:
>> There is no cost in fetching the file type so long you do it
>> while fetching the filename (where is this done?). If you try to fetch
>
> IMHO, it might be too costly to check file types. What's your
>opinion?
>
The type information is directly associated with each file like it's creation date or file permissions. It's not in a separate file, database, or registry. It's cached like all other metadata. The API allows me to fetch only what I want, namely the filename and type (and whatever else Apache wants to know). Just pass one function the inode and you have it. It's only 32bits.
It would be no more costly than a filename which was four characters longer.
Re: modifying MIME handling
Posted by Carlos Costa Portela <cc...@servidores.net>.
On Thu, 9 Aug 2001, Paul Bayley wrote:
> Implementation in source code:
> There is no cost in fetching the file type so long you do it
> while fetching the filename (where is this done?). If you try to fetch
IMHO, it might be too costly to check file types. What's your
opinion?
Best regards, and thank you for your great work, guys,
Carlos.
http://www.improveyourweb.com : All about web, PHP-Nuke based site
[ Web info for and from web people: enjoy it! ]
_______Carlos Costa Portela__________________________________________
| e-mail: ccosta@servidores.net | http://www.registros.net |
| www: http://ccp.servidores.net | http://www.avisaboe.com |
| http://www.biologia.org | http://moana.servidores.net |
|__Tódalas persoas maiores foron nenos antes, pero poucas se lembran__|