Query parameters not passed to form resources
See original GitHub issueDescribe the bug It looks like any form with media hosted on Aggregate is failing to load those media files. For a form with images this fails silently. For a form with external data this fails with an “Unable to auto-detect delimiting character; defaulted to ‘,’” error.
To Reproduce
- get URL to aggregate-hosted survey:
curl --user enketorules: -d "server_url=https://enketo-aggregate.appspot.com&form_id=widgets_on_pages" http://localhost:8005/api/v2/survey/ - load the URL
- inspect failed media download(s) in network tab, see something like:
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>400 Insuffiecent Parameters Received</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Insuffiecent Parameters Received</h1>
</body></html>
Expected behavior Form to load with media resources.
Additional context Link to media manifest on Aggregate for this form: https://enketo-aggregate.appspot.com/xformsManifest?formId=widgets_on_pages
I looks like a link to a download url such as https://enketo-aggregate.appspot.com/xformsDownload?blobKey=aggregate.opendatakit.org%3AFormInfo[%40version%3D1+and+%40uiVersion%3D0]%2F_form_info[%40key%3Dmd5%3Acc0a52104c3e1028d7b23cca46837e72]%2F_form_info_fileset[%40ordinal%3D1]%2FmanifestFileset[%40ordinal%3D1]&as_attachment=true no longer survives into the transformation result.
I believe the whole query part of the download URL is stripped out.
A simpler form without external data: curl --user enketorules: -d "server_url=https://enketo-aggregate.appspot.com&form_id=big-image" http://localhost:8005/api/v2/survey
The regression occurred in 3.0.2
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (7 by maintainers)

Top Related StackOverflow Question
@lognaturel Says it’s not an issue for Central (whew!). @MartijnR how urgently do you need this released?
Thanks for filing this @MartijnR. I believe I’ve found the cause: in https://github.com/enketo/enketo-transformer/pull/111, when provided an absolute/relative URL, only the path is returned. This is obviously incorrect, thankfully it should be a trivial fix.