We are running a small study in rural South Africa, using the full ODK suite (Collect->Aggregate->Briefcase). We have our own Aggregate instance set up locally through a hoster in South Africa, with an SSL certificate from CAcert.
Some time in the last couple days, we have begun experiencing a new issue when attempting to upload forms. The error that is thrown is as follows:
FORM NAME - Error: Moved Permanently (301) at https://URL/study name/submission?deviceID=mac%3A98%3A4b%3A4a%3Aae%3A30%3A1b
This error is observed when trying to upload a completed form. It is not observed when downloading a blank form (which works as expected).
My initial guess is that this is an HTTP protocol error (https://en.wikipedia.org/wiki/HTTP_301), but I can not figure out what caused it. The only thing we have done in the last weeks is uploading new versions of the forms.
Any pointers would be greatly appreciated,
Thanks in advance
Colin
Talk to your hosting service. I assume you do not have multiple custom
website aliases set up to redirect the different study name URLs to a
single running instance of ODK Aggregate, but are running different ODK
Aggregate instances?
For backward compatibility with ODK Collect 1.1.5 and earlier, the ODK
Aggregate server includes a 'Location' header on the response to a
http..../submission request (both the HEAD and POST requests).
Typically, the 'Location' header specifies exactly the same URL (
https://URL/study
name/submission ) as the incoming request. This was used in the earlier
versions of ODK Collect to verify that the submission POST was going to the
ODK Aggregate server rather than to a network login proxy. Within the
current versions of ODK Collect, it is used when processing the HEAD
request to instruct the client to switch to https:// or http:// (depending
upon your configuration) and possibly redirect to a different server path
(e.g., different study name) if so instructed (we explicitly disallow
changes in the server name).
It sounds like your hosting service may be incorrectly processing the
Location header sent in the responses from ODK Aggregate. This should be
sent as-is to the client, but it sounds like there is some sort of network
proxy within their infrastructure that is attempting to interpret and
handle it.
Mitch
···
On Tue, Jul 23, 2013 at 11:24 AM, wrote:
Hi all,
We are running a small study in rural South Africa, using the full ODK
suite (Collect->Aggregate->Briefcase). We have our own Aggregate instance
set up locally through a hoster in South Africa, with an SSL certificate
from CAcert.
Some time in the last couple days, we have begun experiencing a new issue
when attempting to upload forms. The error that is thrown is as follows:
FORM NAME - Error: Moved Permanently (301) at https://URL/study
name/submission?deviceID=mac%3A98%3A4b%3A4a%3Aae%3A30%3A1b
This error is observed when trying to upload a completed form. It is not
observed when downloading a blank form (which works as expected).
My initial guess is that this is an HTTP protocol error ( https://en.wikipedia.org/wiki/HTTP_301), but I can not figure out what
caused it. The only thing we have done in the last weeks is uploading new
versions of the forms.
Any pointers would be greatly appreciated,
Thanks in advance
Colin
Thanks for your suggestions Mitch. I have tried a bunch of other things to narrow down the issues.
I tried messing around with the URL settings, same issue.
I tried changing the username, but get the usual login error as expected.
I added a new form, very basic (no media), same issue (which I think makes the form definition suggestion less likely).
I copied the URL from the error into a browser, URL resolves to a Submission Upload page (which is unexpected).
I upgraded ODK Collect to 1.3, which didn't resolve the issue.
I'm now in a discussion with the server guy to see if he has any suggestions.
We are encrypting the forms, and the SSL certificate may be an issue, which is where I'm going to try looking at now...
As I said, it will be an issue with the hosting service (server guy) *unless
you deployed new ODK Aggregate software immediately before you
encountered this problem, in which case it is likely to be a configuration
error that you made during the running of the installer.
There has been no change in this interface for quite some time.
The form being submitted, or the fact that it is encrypted, will not result
in this error (hence why uploading a new form and submitting to it resulted
in the same 301 error).
The username change further indicates that everything is working up to the
point of ODK Aggregate sending a response with a 'Location' header.
Somehow, the hosting service (server guy) is trying to interpret that
rather than send it back to the user.
···
------
RE: I copied the URL from the error into a browser, URL resolves to a
Submission Upload page (which is unexpected).
Actually, this is exactly expected -- this is the same 'Submission Upload'
page that you would get if you go to Form Management / Submission Admin and
click the 'Manually Upload Submission Data' button. The submission of data
to the server uses standard HTTP form-submission mechanisms, so this simple
web page can be used to submit data manually into ODK Aggregate.
Thanks for your suggestions Mitch. I have tried a bunch of other things to
narrow down the issues.
I tried messing around with the URL settings, same issue.
I tried changing the username, but get the usual login error as expected.
I added a new form, very basic (no media), same issue (which I think makes
the form definition suggestion less likely).
I copied the URL from the error into a browser, URL resolves to a
Submission Upload page (which is unexpected).
I upgraded ODK Collect to 1.3, which didn't resolve the issue.
I'm now in a discussion with the server guy to see if he has any
suggestions.
We are encrypting the forms, and the SSL certificate may be an issue,
which is where I'm going to try looking at now...
I have found a solution which may not be optimal, but is working for now (though still working through the consequences).
On the server end, we had been redirecting all http traffic to https, which seems to have been causing the problem. Now the server accepts both http and https traffic, which isn't optimal, but does seem to have resolved the error. It's not ideal, but at least we can move forward - we'll have to be very diligent that our RAs are using https from the tablets...
At the least, this was a good learning experience! And thanks again for the pointers
The ODK Aggregate installer automatically enforces https if you specify
that you have an SSL certificate, so you should not need any special
configuration in Tomcat or elsewhere.
You can confirm this by attempting to connect using http:// -- it will
redirect to https:// without any changes to the standard Tomcat config, etc.
···
On Tue, Jul 23, 2013 at 3:59 PM, wrote:
Thanks Mitch.
I have found a solution which may not be optimal, but is working for now
(though still working through the consequences).
On the server end, we had been redirecting all http traffic to https,
which seems to have been causing the problem. Now the server accepts both
http and https traffic, which isn't optimal, but does seem to have resolved
the error. It's not ideal, but at least we can move forward - we'll have to
be very diligent that our RAs are using https from the tablets...
At the least, this was a good learning experience! And thanks again for
the pointers