Allow serving Solid-Nextcloud over HTTP (instead of always forcing HTTPS)

[Potherca]

The Solid Specification states:

2.1 HTTP Server

[..] When both http and https URI schemes are supported, the server MUST redirect all http URIs to their https counterparts using a response with a 301 status code and a Location header.

Originally, both Solid Nextcloud and the PHP Standalone severs had https hard-coded for all relevant URLs.

This was done, in part, to protect unknowing users against themselves.

The standalone PHP server soon had logic added that also allowed running the server over http, in order to support development using the built-in web server (as that does not support https).

This was first done by requiring an environmental variable ENVIRONMENT to be set to "development", under the assumption that "production" would always run over HTTPS.

At a later point, a use-case arose in which the server should be able to run over HTTP in production.
The use-case was that the solid pod was served behind either a proxy or a load balancer. The outward facing server was HTTPS, but the inner server was required to run HTP.

In order to support this (and similar) use-cases, the name of the environmental variable was changed to PROXY_MODE.

As @NoelDeMartin mentions in pdsinterop/solid-nextcloud#121, this problem (being able to serve the pod over HTTP) is also present in Solid Nextcloud, but has not been addressed there.

I've given my assurance that this topic would be discussed "internally" but as there is no reason to hold this discussion behind closed doors, I've decided to open this discussion instead.

This can also serve as documentation and as a decision document for future reference.

Things that this discussion should address:

• What are use-cases or scenarios that should allow HTTP?
• What are the constraints within which these (and possible future) use-cases are allowed?
• What is the most desirable implementation route for this?

I would specifically like input from @ylebre, as he was involved in this discussion at the time for the standalone server.

[NoelDeMartin]

How will we guard against HTTP outside the defined cases?

I think it'd be better not to guard against other use-cases, rather the extension/server could do some smart things to decide whether the server is running under http or https, but always have a scape hatch to allow developers to force a given schema. I agree that defaults are important to avoid unintended consequences (someone not using https without being aware of the full consequences). But I also think in the end software should be configurable to meet the needs of users that "know what they are doing". For example, just off the top of my head I can come up with another use-case: Running a POD on a local network, and not bother adding https because the traffic within this network is trusted. I'm sure there could be more use-cases that escape our imagination (now or in the future).

[Potherca]

I think it'd be better not to guard against other use-cases

Your point is valid. I think what I am looking for is not so much to guard against use-cases, but to guard the constraint within which use-case will be allowed. So "constraint" might be a better word than "guard". I've updated the wording to better reflect this intent.

Some constraints that come to mind are:

• The protocol should be mutually exclusive. Either the plugin runs HTTP or it runs HTTPS.
• It should not be possible to switch protocols during run-time. I.e. once the server is set to one protocol, there may not be logic that allows switching to another protocols.
• The user should not be able to request HTTP or HTTPS. Only the server may decide.
• If Nextcloud is served over HTTPS, then the plugin should also be served over HTTPS.

As to configuration, the question arises what the configuration path should be. Should it come from a DB? Environment? Is a UI needed?
Especially in relationship to "protecting unaware users against themselves" a UI might spell trouble. On the other hand, if an environment variable is chosen, would that suffice? Or are there use-cases where a user would not have access to the environment?

I'm sure there could be more use-cases that escape our imagination (now or in the future).

I think we should at least mention some use cases to give an idea of intent. I agree that this should be informative, not exhaustive.
In part this is also meant a first input to "How to do X" kind of things, allowing us to point to specific documentation.

[ylebre]

If we are not going to enforce HTTPS, we should remove it completely from the implementation and follow whatever the protocol schema is that is used to access it. This will allow configurations where a Nextcloud configuration is on both http and https and still produce the expected results. Automatically following whatever our 'host' is doing will also remove the need for another thing to configure in the solid app.

[Potherca]

I think removing the current implementation would check all the boxes:

• It should not be possible to switch protocols during run-time. I.e. once the server is set to one protocol, there may not be logic that allows switching to another protocols.
• The user should not be able to request HTTP or HTTPS. Only the server may decide.
• If Nextcloud is served over HTTPS, then the plugin should also be served over HTTPS.

With the exception of

• The protocol should be mutually exclusive. Either the plugin runs HTTP or it runs HTTPS.

Since it would be up to the Nextcloud serving specifics wether either protocal, or both, are allowed. But this point would become redundant, as the responsibility is shifted "up" to the Nextcloud instance itself.

I think it also neatly connect to "least surprise" and would also be sufficient to protect unaware users against themselves.

We could still add mention in the documentation (specifically for development) about the details of http/https.