File-upload-widget not working on ODK Aggregate v2.0.2

Support
1

ODK Collect App v1.21.1
ODK Aggregate v2.0.2

I have an ODK form with the file-upload-widget that I want to use to send gps tracks (.gpx) files to an Aggregate server. (I don't want to use GeoODK as I want to use a handheld GPS to collect the data). The files do not appear on the server.

I have run some tests by creating a very small (<500 byte) .gpx file (to exclude file size limits) which I renamed as a .jpg, .pdf and .kml. I tried uploading all four (.gpx, .jpg, .pdf and .kml) to the Aggregate server. Only the .jpg appeared. I received no error message.

2

@kkrawczyk123 or @mmarciniak90 did you notice the same, if not please check.

3

I was able to reproduce this problem.
It looks like a more general problem with recognizing files.
I need to investigate it and after that, I will report an issue.

@Grzesiek2010

EDIT: Issue reported https://github.com/opendatakit/aggregate/issues/455

1 Like
4

Thanks for picking this up :grinning:

5

Hi, all!

I've studied this issue and here are my findings:

  • Collect makes a pre-flight HEAD request before sending a submission
  • Aggregate v1.7.2 responds with an HTTP 204 No Content message that includes a Location header
  • According to the HTTP standard, Location headers should be added to 3xx redirection responses and to 201 and 202 responses (for newly created resources). There's no mention about 204 responses. Also, it doesn't really make sense to add a Location to a No Content response.
  • Aggregate v2.0 removed the header to comply with the HTTP standard.
  • Collect doesn't add attachments to the HTTP POST request that makes to upload submissions to Aggregate if the Location header is not present in the pre-flight HEAD request.
    • I've verified that by restoring the Location header in v2.0, which fixes the issue

I'm sorry that an apparently safe fix in Aggregate has produced this problem!

We can restore the header in Aggregate, alhough it feels like Collect shouldn't rely on the presence of a non-standard header that doesn't add any useful information. We could consider fixing this in Collect too.

I'm also wondering if this is really part of the OpenRosa protocol specification...

6

See https://docs.opendatakit.org/openrosa-form-submission/#extended-transmission-considerations for related spec.

We'd have to make sure that changing Collect wouldn't affect other server implementations.

7

Sorry I doubted you, @ggalmazor, this is indeed a weird Collect issue. Thanks for cross-linking https://github.com/opendatakit/central/issues/47, @issa.

Changing Collect seems like the right way to go (https://github.com/opendatakit/collect/pull/3038). It looks like the Location header was used to identify Aggregate versions greater than 0.9 and to filter out media file types incompatible with Aggregate 0.9. I think Aggregate should continue to send the Location header for some time as clients catch up on updates.

2 Likes
8

Aggregate v2.0.3 adds the Location header back in to support Collect v1.21.1 and earlier. Collect v1.21.2 removes the file filtering based on the Location header so it should work with Central and Aggregate v2.0.0-2.0.2.

If you are running into this issue, you have the option of upgrading Aggregate to 2.0.3 or upgrading Collect to 1.21.2 (or both).

image

1 Like