Should kit.host be replaced with something like kit.base?

[hgl]

Is your feature request related to a problem? Please describe.
This expends on #1240 to discuss the protocol value.

An obvious choice might be introducing kit.protocol, but that feels awkward.

Describe the solution you'd like
A cleaner solution might be something that is basically protocol + host, e.g., kit.base, and svelte kit should extract host from it.

If kit.base doesn't contain the protocol, it's inferred from svelte kit being in https mode or not.

page can also contain a protocol property in addition to host

As for kit.hostHeader, I think it can be left as it is, but we might need to introduce a kit.protocolHeader that can take a value like 'X-Forwarded-Proto'.

I don't feel strongly about the naming, just my two cents.

Describe alternatives you've considered

How important is this feature to you?
Not very, but nailing this down before 1.0 can be beneficial, since this is likely a breaking change.

Additional context

[Conduitry]

See #1193. We don't have access to whether the app is being served over HTTPS in production. And --https is adev- and preview-only thing. If you want to trust the x-forwarded-proto value, you can already expose it in the session.

[hgl]

Ah, makes sense.

But I think svelte kit doesn't have to be absolutely accurate when it comes to determining the protocol, as long as users can specify it manually in the config.

When the user doesn't specify one, assuming http by default and https when --https is used in dev/preview sounds like a pretty intuitive convention to me.

P.S., a tangent question, maybe node adapter can support https in the future? By that I mean the built app is able to run in https by itself. I'm asking because that sounds like another place where svelte kit can reasonably infer the protocol.

[Rich-Harris]

Closing this as it can't be solved without additional configuration that is best expressed in userland. adapter-node could support https in future, but it's more conventional to put the server behind a reverse proxy