Dev mode with Vite doesn't support https

[chkpnt]

Describe your motivation

Currently, the Vaadin dev mode doesn't support https.

Vite can be configured to start a TLS endpoint like this:

// vite.config.ts

const customConfig: UserConfigFn = (env) => ({
    // Here you can add custom Vite parameters
    // https://vitejs.dev/config/
    server: {
        host: "service-localdev.example.com",  // resolves to localhost
        https: {
            key: fs.readFileSync("../assets/tls/localdev/service-localdev.example.com.key"),
            cert: fs.readFileSync("../assets/tls/localdev/service-localdev.example.com.crt")
        }
    }
});

which is also recognized by Vaadin:

2022-10-05 15:06:49.856  INFO [                ] c.v.b.devserver.AbstractDevServerRunner  : Started Vite. Time: 2092ms
2022-10-05 15:06:49.857  INFO [                ] c.v.b.devserver.DevServerOutputTracker   :   ➜  Local:   https://service-localdev.example.com:57132/ui/VAADIN/
2022-10-05 15:06:49.857  INFO [                ] c.v.b.devserver.DevServerOutputTracker   :   ➜  Network: https://10.67.0.214:57132/ui/VAADIN/

But unfortunately, Vaadin uses a hardcoded DEV_SERVER_HOST of "http://127.0.0.1" (see AbstractDevServerRunner), which leads to a failing connection establishment:

java.net.SocketException: Unexpected end of file from server
	at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:866) ~[na:na]
	at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) ~[na:na]
	at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:863) ~[na:na]
	at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) ~[na:na]
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1615) ~[na:na]
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1520) ~[na:na]
	at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527) ~[na:na]
	at com.vaadin.base.devserver.AbstractDevServerRunner.serveDevModeRequest(AbstractDevServerRunner.java:723) ~[vaadin-dev-server-23.2.3.jar:na]
	at com.vaadin.flow.server.StaticFileServer.serveStaticResource(StaticFileServer.java:243) ~[flow-server-23.2.3.jar:23.2.3]
	at com.vaadin.flow.server.VaadinServlet.serveStaticOrWebJarRequest(VaadinServlet.java:401) ~[flow-server-23.2.3.jar:23.2.3]
	at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:356) ~[flow-server-23.2.3.jar:23.2.3]
	at com.vaadin.flow.spring.SpringServlet.service(SpringServlet.java:106) ~[vaadin-spring-23.2.3.jar:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:764) ~[tomcat-embed-core-9.0.65.jar:4.0.FR]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) ~[tomcat-embed-core-9.0.65.jar:9.0.65]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.65.jar:9.0.65]
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) ~[tomcat-embed-websocket-9.0.65.jar:9.0.65]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.65.jar:9.0.65]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.65.jar:9.0.65]

It's a common use case and best practice to use https everywhere, even on localdev. In my case, I'm further required to use https, as I'm using SPNEGO (Kerberos) as an authentication scheme.

Describe the solution you'd like

Vaadin should use the scheme and host of the Vite dev server.

Describe alternatives you've considered

I'm unsure if this is needed at all. If the vite dev server is used internally only, using http://localhost is fine. But unfortunately, the client itself is trying to connect to the dev server directly, which fails if the Spring Boot application is using https and the Vite dev server is only available via http://localhost:

So probably a cleaner approach would be to proxy each request to the Vite dev server through the Vaadin application.

Additional context

In my example, the Spring Boot application is providing the TLS endpoint. But this is not a necessity: Another valid way to develop https-only locally is to use a local reverse proxy. Even then, the dev mode should be usable.

[roeltje25]

This is also blocking us here. I cannot understand why it is marked as an enhancement. II cannot explain this to my colleagues and supervisors here. This is clearly a (blocking) bug.

[Artur-]

The workaround would be to use webpack until this is resolved

[Legioth]

The enhancement label was added by the person who created the issue through using that specific issue template. The team that maintains the code in question hasn't yet triaged the issue. I'll remove the label for now to avoid any confusion.

[Artur-]

If I understand correctly then this would be fixed by doing https://github.com/vaadin/flow/issues/14773#issuecomment-1271551575

[chkpnt]

Yeah, I chose Feature Request, as it isn't clear to me if https-dev-mode has been documented as supported with webpack or if it just worked unintentionally.

[Avec112]

I also do experience problems with Vite after upgrading from v23.2.0 to v23.2.9. But I am not sure if it is related to TLS addresses or not but anyhow my login page is not being rendered. We are referencing ldaps:// and do not have an option for temporary downgrade if this is the actual problem. If I switch from using Vite to Webpack the problem is gone. However using Webpack also removes Live Reload for some reason and that sucks.

[Artur-]

This particular issue only occurs if you configure your dev server to listen to https instead of http. Anything else would be a separate/different problem

[Avec112]

Aha. Well in that case I should create a separate bug.