I would suggest dropping the code which checks for supported content types as I don't think it really serves any useful purpose - just creates a maze of different browser peculiarity behaviour. We can (and do) deduce if the stream is a zip or a gzip by looking at the header bytes. If it's not we have a go and see if its xml parseable. I don't think there is nothing else immediately useful to us being provided by the browser reported mime-type. Does anyone have any objection to dropping this? I could be missing something important ...
Regards Bob 2010/4/3 Lars Helge Øverland <[email protected]>: > I have added application/octet-stream to the allowed content types as a > work-around for now. > Lars > > On Wed, Mar 31, 2010 at 8:40 AM, Jason Pickering > <[email protected]> wrote: >> >> I tried with Opera and it worked. Seems to be either a bug or perhaps >> malware that is causing this. >> >> Does not seem to be a bug with DHIS2 though, so I will not file a bug >> report I guess. However, it is a problem that we need to figure out how to >> resolve. >> >> >> >> On Tue, Mar 30, 2010 at 11:37 PM, Jo Størset <[email protected]> wrote: >>> >>> Den 30. mars 2010 kl. 21.22 skrev Jason Pickering: >>> >>> 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? >>> >>> I don't think it's a common problem, most clients should be reporting >>> correctly for standard files and this is the first time we have encountered >>> such a problem. Does anybody else know of any similar problems with dhis? >>> It should be possible to work around the problem in your case, if it is >>> what I suspect. As you say, it has been working before. Import should work >>> in most browsers, if you could try another one it would help. If you could >>> use something like the live http header plugin [1] to log the POST request >>> being sent, it would also verify what content-type firefox sends. >>> If we accept application/octet-stream, I think we might as well drop the >>> content type checking. And I guess that should work fine. Notice that we >>> currently more or less have option 3 (with 1 in addition), so 3 might not be >>> *that* dubious :) Bob has been talking about switching to 2, I guess since >>> sdmx-hd might come with different envelope formats (i.e. xml, zip, gzip). >>> I'm leaving on easter break tomorrow, and Lars/Bob seem to have already >>> left. So I guess it will have to wait a couple of days. >>> Jo >>> [1] https://addons.mozilla.org/en-US/firefox/addon/3829 >> >> >> >> -- >> -- >> Jason P. Pickering >> email: [email protected] >> tel:+260968395190 >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-devs >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
