Yeah, I figured this out actually after I had done it. Oh well, it was worth a try.
This seems like a major limitation really, well, at least when it comes to importing DHIS 1.4 XML zip files. Would it be possible simply to add the application/octet-stream as an acceptable type? Using some Java applet might be a way to accomplish 1 and 2. 3 seems pretty dubious. :) I mean, if the file is bogus, DHIS2 should simply just ignore it and trash the file right? On Tue, Mar 30, 2010 at 5:55 PM, Jo Størset <stor...@gmail.com> wrote: > > Den 30. mars 2010 kl. 16.43 skrev Jason Pickering: > > > Typically in the past, when I have seen this error message, I have added > this to the web.xml file of Tomcat.. > > > > <mime-mapping> > > <extension>zip</extension> > > <mime-type>application/application-octet</mime-type> > > </mime-mapping> > > Ah, ok, that's the other way around, the content type set on resources > tomcat is serving. > > For file uploads, the content type of the request is multipart/form-data, > with the uploaded file + content type in the request body. So generally it > is not something the server container wants to mess with. We basically have > three choices: > 1) trusting what the client is reporting > 2) have our own way of deducing based on the content itself (can be tricky > and require resources on the server side). > 3) have a separate form field, where the user explicitly states the file > format > > I guess we might want a combination of 2 and 3 for our use cases. > > Jo -- -- Jason P. Pickering email: jason.p.picker...@gmail.com tel:+260968395190
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
