dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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 <larshelge@xxxxxxxxx>:
> 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
> <jason.p.pickering@xxxxxxxxx> 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 <storset@xxxxxxxxx> 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: jason.p.pickering@xxxxxxxxx
>> tel:+260968395190
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>