I'm consistently receiving HTTP 303 ("See Other") redirection to HTTP 500 error responses from our Valence API when trying to retrieve the structure for a handful of modules. (Handful = 20-30 modules out of about 19,000). The ones that fail consistently fail, but can be viewed through the web UI without issue.
Here's a cURL request of a failing request:
GET /d2l/api/le/1.4/420523/content/modules/2872608/structure/?x_a=...&x_b=...&x_c=...&x_d=...&x_t=... HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.18 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: d2l.deakin.edu.au
Accept: */*
And the response:
HTTP/1.1 303 See other
Cache-Control: private
Content-Length: 0
Location: /d2l/error/500
Server: Microsoft-IIS/7.5
X-XSS-Protection: 0
X-Powered-By: ASP.NET
Date: Mon, 16 May 2016 05:13:37 GMT
The modules that I've looked up in the web UI don't seem any different to any other module, for example a module might contain 3 sub-modules, all with topic-only content, and one of the modules gives a 303 response, 2 do not. There are a couple of org units with 2 or 3 "bad" modules, but mostly they're singular.
I've also tried this at API versions 1.1 -> 1.4 (we are currently on v1.4)
I also raised a support call with the vendor for this issue.
It turns out to be a bug in Valence API versions <= 1.4, triggered by a module containing a topic file which ends in a dot/period (hence having the form some_file..ext once its given an extension).
Solution: upgrade to Valence 1.6 where the bug is fixed, or rename affected files.