I'm not sure whether this is an issue in Octoprint, Octopi or a combination since Octoprint doesn't do HTTPS on its own. It looks like some requests are still going over HTTP even though I'm accessing the server via HTTPS.

Chrome version is 38.0.2125.111 (64-bit) under Linux. In Chrome's developer console, I get the following when attempting to load a gcode file to print:

[blocked] The page at 'https://hostname.domain.com/' was loaded over HTTPS, but ran insecure content from 'http://hostname.domain.com/api/files/local/Z-Axis_LM8UU_Bearing_Holder.A6.gcode': this content should also be loaded over HTTPS.
x.support.cors.e.crossDomain.send jquery.min.js:6
x.extend.ajax jquery.min.js:6
GcodeFilesViewModel.self.loadFile files.js:142
click VM311:3(anonymous function) knockout.js:62
x.event.dispatch jquery.min.js:5y.handle

If I click on the shield at the top, to "load unsafe script", I receive the following message instead:

XMLHttpRequest cannot load http://hostname.domain.com/api/files/local/Z-Axis_LM8UU_Bearing_Holder.A6.gcode. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://hostname.domain.com' is therefore not allowed access.

This seems to have started happening sometime in October, but I'm not sure exactly when. I can replicate it using a fresh install from 2014-09-09-wheezy-octopi-0.10.0.zip (* master 644329c Preparing release of 1.1.1), as well as an install from 2014-01-07-wheezy-octopi-0.8.0.zip with Octoprint which had been periodically upgraded via the recommended method ultimately to whatever was available in Github as of the evening of 2014-11-05, which was where I originally discovered it.