On Feb 11, 2011, at 7:35 PM, Aparajita Fishman wrote: >> Because these files are entirely arbitrary, I can't reasonably expect >> that a file the user sends to me will be represented in >> ExtensionMap.ini. > > The files can't be *entirely* arbitrary, there are a finite number > of file extensions in use in the world.
Perhaps, but the list is very long, and since we're no longer in the DOS days of a 3-character extension limit the number of possibilities is larger than I care to manually attempt to map. The types of data we're expecting come from a wide range of different and obscure platforms so I wouldn't even want to start guessing as to the universe we'll actually see. >> 1) The documentation for "get upload content type()" says it >> returns a >> MIME type based on the file extension, which implies that it uses >> ExtensionMap.ini to determine a MIME Type. However, in practice this >> doesn't seem to be true. It appears that it actually will return the >> MIME Type that the browser asserted when the file was uploaded > > The documentation is wrong, the type is taken from the browser. Ok, good, that agrees with my testing. > >> 2) Why does "write blob" cause an error if passed a MIME type it >> doesn't understand? > > Because 'write blob' does double duty for writing text in blobs and > writing binary files. The only way I could determine which behavior > to use (before Active4D 4.5) was to check the MIME type or file > extension. In 4.5 I added the ability to force binary behavior. That makes sense. I saw that the 4.5 docs added a "force binary" argument, does that imply that if I force binary it will allow me to specify an arbitrary MIME type without crashing? > >> 3) I may have overlooked it, but if "write blob" really needs to >> understand the MIME type to function, is there some method I can call >> to test whether my type is supported before I crash my script? > > No. In retrospect the limitation of having a known MIME type is > unnecessary beginning with v4.5 if binary output is forced, but > there is nothing I can do about it now. The only solution available > is to add a ton of entries to ExtensionMap.ini that will hopefully > cover any file types you encounter. For an exhaustive list, see here: > > https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/ > mime.types > > If the file does not have a type in that list, you'll have to use > application/octet-stream when returning the file, which really isn't > a big deal, since the OS on the client side really only cares about > the filename extension. Thanks for the pointer. If the "force binary" option won't do the trick (we'll be upgrading this year) I'll take a look at using that MIME type list. Thanks for your help, Chris Backas Bristol Capital, Inc. CONFIDENTIALITY NOTICE: This email (and any related attachments) contains information from InfoPlus (a service of Bristol Capital, Inc.). It is intended only for the addressee and may contain information that is confidential and/or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or are acting as agent for the intended recipient, any use or disclosure of this communication is prohibited. If you have received this communication in error, please notify me immediately to arrange for the appropriate method of returning or disposing of the communication. If our respective Companies have confidentiality provisions in effect, this email and the materials contained herein are deemed CONFIDENTIAL and should be treated accordingly unless expressly provided otherwise. _______________________________________________ Active4D-dev mailing list [email protected] http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
