dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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 <storset@xxxxxxxxx> 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.pickering@xxxxxxxxx
tel:+260968395190