Why OpenCloud still answers /status.php

OpenCloud is written in Go. Its /status.php route is a compatibility endpoint for existing clients, not a PHP script.

• Why OpenCloud still answers /status.php
• Where the path comes from
• What the handler actually returns
• What this scanner reads from it, and what it does not

Where the path comes from

The endpoint preserves a familiar client interface while OpenCloud serves it from Go code. The .php suffix does not imply that PHP runs on the server. Several products expose a compatible endpoint, so the scanner checks the reported product before applying OpenCloud-specific rules. See What OpenCloud is for the architecture and Troubleshooting for product-identification failures.

// vendor/github.com/opencloud-eu/reva/v2/internal/http/services/owncloud/ocdav/ocdav.go
return []string{"/status.php", "/status", "/remote.php/dav/public-files/", ...}
...
case "status.php", "status":
    s.doStatus(w, r)

Both /status.php and the shorter /status reach the same handler. The .php spelling is kept only because clients still ask for it by that exact name; nothing about the response is generated by PHP.

What the handler actually returns

The handler that answers both paths is doStatus, and its response is a struct literal, not a query against any live state:

// vendor/github.com/opencloud-eu/reva/v2/internal/http/services/owncloud/ocdav/status.go
status := &ocs.Status{
    Installed:      true,
    Maintenance:    false,
    NeedsDBUpgrade: false,
    Version:        s.c.Version,
    VersionString:  s.c.VersionString,
    Edition:        s.c.Edition,
    ProductName:    s.c.ProductName,
    ProductVersion: s.c.ProductVersion,
    Product:        s.c.Product,
}

Installed, Maintenance and NeedsDBUpgrade are literal true/false/ false - not s.c.something, not read from a database, not read from a file on disk. Every OpenCloud instance that has ever shipped this handler returns exactly the same three values for them, regardless of whether it just started, is mid-deployment, or has been running for a year. OpenCloud has no database in the sense the field name implies either: it stores data in the filesystem and object storage backends, not a schema-migrated SQL database, so "needsDbUpgrade" describes a state OpenCloud's own architecture does not have.

The remaining fields - Version, VersionString, Edition, ProductName, ProductVersion, Product - come from s.c, the service's own configuration, and do vary by build. Version and VersionString are themselves fixed legacy placeholders kept for old sync clients; only ProductVersion is the real release - see Reading the version correctly.

What this scanner reads from it, and what it does not

This scanner reads product/productname (to refuse ownCloud and Nextcloud rather than rate them) and productversion (the actual release, used for the end-of-life and update checks - see Version and lifecycle disclosure for what depends on that field, and how the scan copes when it is missing). It does not check installed, maintenance, or needsDbUpgrade: a check that always passes - regardless of what is actually happening on the server - would be worse than no check at all, because a green result would imply the scanner had verified something it could not possibly have observed. Earlier releases of this scanner did report maintenanceMode, installed and databaseUpgrade findings from these fields; they were removed once the hardcoded response above was confirmed against OpenCloud's own source.

If a future OpenCloud release starts computing these fields from real state, the source above is the place to check - it is the authoritative answer, not this document, which only quotes it at the time of writing.