When no storage is up, `storage_running()` renderer will return a big
honking `no storage server running` message, and no further renderers
will be invoked. Therefore the extra defense is probably not
required.
(I tested this hypothesis. The extra defense is not required, unless
there's something I have not seen.)
Related to ticket:3247
test_storage.py wants a `StorageStatus::renderSynchronously()` method
and a `StorageStatus::renderHTTP()` method. Let us begin with the
goofy first-cut.
Both these methods are not only wrong, but they will also not please
the test suite. However error messages produced in CI can be shared,
and that way I can hopefully get unstuck.
Related to ticket:3247. Nevow usage has been removed, and generated
page looks the same as its former self, but tests are failing because
test_storage.py assumes that we're using nevow.
This seems to be a subtle difference from nevow: with `href="."`,
rendered link target will be `/uri/`, so clicking "Refresh" will
result in an error message like so: "GET /uri requires uri=".
With `href=""`, the rendered link target will be `/uri/URI:...`, which
is what we need.
We need self.render_POST() etc. to be invoked when we have a request
such as "POST /uri/URI:DIR:..."; throwing an error here is probably
not the right thing to do.
Several problems with using RuntimeError to signal error here:
- It dumps a rather unhelpful webpage at the user.
- The exception backtrace on Tahoe console is not quite necessary here.
- It really is not a runtime error: it is just an expected failure.
- But mainly, testing for RuntimeError is harder.
Both UploadResultsRenderer and DownloadResultsRenderer do not use
RateAndTimeMixin anymore: safe to remove it now.
Tests for methods formerly in RateAndTimeMixin have been moved to
test.web.test_util: specifically test_abbreviate_rate() and
test_abbreviate_time().
