dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

The initial purpose was to avoid confusion when users uploaded the raw
dxf instead of the zip, and avoid nasty stacktraces when irrellevant
files were uploaded..

2010/4/4, 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
>>
>>
>

-- 
Sendt fra min mobile enhet