Content type not allowed during DHIS 1.4 file import

Support - Assistance technique
1

I got this message while trying to import a DHIS 1.4 file…

  • WARN 13:37:02,027 Content type not allowed: application/octet-stream (ImportAction.java [http-8080-5])

I suspect this might be a Tomcat security issue, but at least we should document it.

Suggestions?

···

–

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

2

Basically, when uploading a file, the client (browser) reports a content type for the file uploaded. In this case your browser is reporting a file of type application/octet-stream, which the code does not allow (currently it accepts "application/x-zip-compressed", "application/zip", "application/x-gzip" and "text/xml").

This is a bit of a tricky area... I you are sitting on windows, I would guess you were uploading a file without a file type extension. As a quick fix, try to add the correct file type extension or use a different browser (though I guess we only officially support firefox for now).

I guess we maybe shouldn't care about the browser reported content type here. We know what we are looking for, so we should have other means of checking the content type. Bob has been looking at the import module architecture, maybe he has an opinion when he's back from Barcelona.

Jo

···

Den 30. mars 2010 kl. 13.42 skrev Jason Pickering:

I got this message while trying to import a DHIS 1.4 file..

* WARN 13:37:02,027 Content type not allowed: application/octet-stream (ImportAction.java [http-8080-5])

I suspect this might be a Tomcat security issue, but at least we should document it.

Suggestions?

3

Hi Jo,
Well, it it just a zip file. That is what does not make a lot of sense.

It has the zip extension. ???

I would agree that we should probably just ignore it, or allow it. I tried adding it to the main web.xml file, but this did not work.

Regards,
Jason

···

On Tue, Mar 30, 2010 at 3:03 PM, Jo Størset storset@gmail.com wrote:

Den 30. mars 2010 kl. 13.42 skrev Jason Pickering:

I got this message while trying to import a DHIS 1.4 file…

  • WARN 13:37:02,027 Content type not allowed: application/octet-stream (ImportAction.java [http-8080-5])

I suspect this might be a Tomcat security issue, but at least we should document it.

Suggestions?

Basically, when uploading a file, the client (browser) reports a content type for the file uploaded. In this case your browser is reporting a file of type application/octet-stream, which the code does not allow (currently it accepts “application/x-zip-compressed”, “application/zip”, “application/x-gzip” and “text/xml”).

This is a bit of a tricky area… I you are sitting on windows, I would guess you were uploading a file without a file type extension. As a quick fix, try to add the correct file type extension or use a different browser (though I guess we only officially support firefox for now).

I guess we maybe shouldn’t care about the browser reported content type here. We know what we are looking for, so we should have other means of checking the content type. Bob has been looking at the import module architecture, maybe he has an opinion when he’s back from Barcelona.

Jo

–

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

4

Hi Jo,
Well, it it just a zip file. That is what does not make a lot of sense.

It has the zip extension. ???

I am pretty sure this is a client bug of some sort. Do you have another browser you could try?

I'm sitting on a mac, so I don't have detailed experience with the windows side of things. But what about changing the file extension to something else and back again?

There are reports of similar problems, but old:

http://forums.mozillazine.org/viewtopic.php?f=38&t=626413&start=0&st=0&sk=t&sd=a

I would agree that we should probably just ignore it, or allow it. I tried adding it to the main web.xml file, but this did not work.

I'm not really sure what you tried to do, but the accepted content types are set in the ImportAction class.

We will probably change this, but it will need to be in the longer time frame. We need some way of deciding what content type the input is, and I am not sure we have an effective way of doing that as of now. If a large file is uploaded, we need to ensure we have an effective way of deduce the content type. But since we are dealing with multiple xml formats anyway (that have the same content type), I guess we need something better.

Jo

···

Den 30. mars 2010 kl. 15.47 skrev Jason Pickering:

5

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>

This seems to be more of an issue with Firefox. I know it worked previously. I am using WIndows, but can try from Linux tomorrow and see. This function has previously worked, so it looks like it may be just a browser issue. Strange…

···

On Tue, Mar 30, 2010 at 4:33 PM, Jo Størset storset@gmail.com wrote:

Den 30. mars 2010 kl. 15.47 skrev Jason Pickering:

Hi Jo,

Well, it it just a zip file. That is what does not make a lot of sense.

It has the zip extension. ???

I am pretty sure this is a client bug of some sort. Do you have another browser you could try?

I’m sitting on a mac, so I don’t have detailed experience with the windows side of things. But what about changing the file extension to something else and back again?

There are reports of similar problems, but old:

http://forums.mozillazine.org/viewtopic.php?f=38&t=626413&start=0&st=0&sk=t&sd=a

I would agree that we should probably just ignore it, or allow it. I tried adding it to the main web.xml file, but this did not work.

I’m not really sure what you tried to do, but the accepted content types are set in the ImportAction class.

We will probably change this, but it will need to be in the longer time frame. We need some way of deciding what content type the input is, and I am not sure we have an effective way of doing that as of now. If a large file is uploaded, we need to ensure we have an effective way of deduce the content type. But since we are dealing with multiple xml formats anyway (that have the same content type), I guess we need something better.

Jo

–

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

6

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

···

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>

7

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. :slight_smile:

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@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.pickering@gmail.com
tel:+260968395190

8

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@gmail.com 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. :slight_smile:

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 :slight_smile: 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@gmail.com
tel:+260968395190

9

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@gmail.com 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@gmail.com 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. :slight_smile:

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 :slight_smile: 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@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

10

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@gmail.com>:

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@gmail.com> 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@gmail.com> 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. :slight_smile:

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 :slight_smile: 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@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

_______________________________________________
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

11

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@gmail.com>:

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@gmail.com>:

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@gmail.com> 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@gmail.com> 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. :slight_smile:

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 :slight_smile: 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@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

_______________________________________________
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

--
Sendt fra min mobile enhet

12

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..

OK. I'll take it out and find another way of dealing with nasty stack traces.

Bob.

···

2010/4/5 Lars Helge Øverland <larshelge@gmail.com>:

2010/4/4, Bob Jolliffe <bobjolliffe@gmail.com>:

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@gmail.com>:

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@gmail.com> 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@gmail.com> 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. :slight_smile:

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 :slight_smile: 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@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

_______________________________________________
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

--
Sendt fra min mobile enhet

13

Thanks. This seems to work. I got the latest code, but switched
broswers (from Firefox to Opera) and OSes (from Windows to Linux) so
not really sure if this is a real fix.

Anyway, things sort of proceed as I expect, except, I do not see any
data actually being imported..what am I missing here?

Also, this bug is still affecting me..

https://bugs.launchpad.net/dhis2/+bug/445299/

Stacktrace of the import is here..http://pastebin.com/xEQs6xuy

Regards,
Jason

···

2010/4/5 Bob Jolliffe <bobjolliffe@gmail.com>:

2010/4/5 Lars Helge Øverland <larshelge@gmail.com>:

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..

OK. I'll take it out and find another way of dealing with nasty stack traces.

Bob.

2010/4/4, Bob Jolliffe <bobjolliffe@gmail.com>:

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@gmail.com>:

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@gmail.com> 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@gmail.com> 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. :slight_smile:

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 :slight_smile: 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@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

_______________________________________________
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

--
Sendt fra min mobile enhet

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190