Hackathon 25.3: no server side way to build a route's absolute URL

[manolo]

Description

There is no server side way to build a route's absolute URL. RouterLink and RouteConfiguration.getUrl produce paths relative to the context root, which is right for navigating and useless for a link that leaves the browser: an email, an invoice, something copied to the clipboard. The only absolute answer, Page.fetchCurrentURL, is a round trip to the client and asynchronous, so it cannot be used while building the component that needs the value.

Every application that emails a link writes the same thing: read the scheme, authority and context path off the VaadinServletRequest the call arrived on, and decide for itself what to do behind a reverse proxy.

Nothing lets an application ask what it is licensed for.** GridPro.class contains no reference to the licence checker: the check happens elsewhere, and LicenseChecker.isValidLicense answers the same for a product name that does not exist as for one that does. So an application cannot adapt, and cannot even tell whether adapting would be needed. We do not want a licence probe in application code, and we hit this while deciding whether a core only branch was possible. The answer had to come from reading jars

How this was checked

Every URL method RouteConfiguration declares in 25.3.0-beta1, and all of them answer a path:

public String getUrl(Class<? extends Component>)
public Optional<String> getUrlBase(Class<? extends Component>)
public <T, C ...> String getUrl(Class<? extends C>, T)
public <T, C ...> String getUrl(Class<? extends C>, List<T>)
public String getUrl(Class<? extends Component>, RouteParameters)

Expected

RouteConfiguration.getAbsoluteUrl(Class, parameters), or an absolute form of the existing helpers.

And either a component level isLicensed(), or a documented product identifier per component so the existing checker can be asked a real question.

Found on 25.3.0-beta1.

[totally-not-ai]

Thanks @manolo — I've dug through the code. Summary: part 1 (absolute route URL) is a valid gap and worth doing, but it needs an API decision before code. Part 2 (licensing) is real too, but it isn't a Flow issue and should move.

1. Absolute route URL — confirmed gap

RouteConfiguration is entirely request-unaware. The single real implementation behind all five URL methods is:

// RouteConfiguration.java:555
public String getUrl(Class<? extends Component> navigationTarget, RouteParameters parameters) {
    Optional<String> targetUrl = handledRegistry.getTargetUrl(navigationTarget, parameters);
    ...
    return targetUrl.get();
}

It returns a bare registry-relative path — no leading slash, no context path, no servlet mapping, no origin. RouterLink doesn't add anything either (RouterLink.java:440 updateHref only encodes and appends the query string). The context path never appears server-side at all: Flow emits a relative <base href> (BootstrapHandlerHelper.getServiceUrl → HandlerHelper.getCancelingRelativePath, i.e. "." / "../..") and lets the browser do the absolutizing. That's a deliberate choice, spelled out at AppShellRegistry.java:303:

Use the servlet-relative path (e.g. "./", "../") rather than the absolute context path. The emitted href is then resolved by the browser against <base> … works correctly behind reverse proxies that rewrite the public path.

So the framework's URL strategy is "stay relative, the client absolutizes" — which is exactly why there is no server-side answer, and why Page.fetchCurrentURL (Page.java:790, a window.location.href round trip) is the only reliable one today.

The building blocks already exist, but are all private or partial:

• VaadinServlet.getApplicationUrl(HttpServletRequest) (VaadinServlet.java:597) — package-private static, builds scheme://host[:port] + contextPath + servletPath. Exactly the reconstruction being asked for, just not reachable, and it uses raw isSecure()/getServerName()/getServerPort().
• NavigationAccessControl.getRequestURL(VaadinRequest) (:363) — protected, servlet-only (instanceof VaadinServletRequest), returns "" otherwise. Already used to store SESSION_STORED_REDIRECT_ABSOLUTE, so Flow does build an absolute URL in one place.
• VaadinService.getContextRootRelativePath(VaadinRequest) — relative by design.
• UrlUtil has no absolute-URL construction at all.

Two constraints any design has to face:

1. VaadinRequest is not enough. VaadinRequest exposes getContextPath()/isSecure() but not getRequestURL()/getServerName()/getServerPort() — those come from HttpServletRequestWrapper on VaadinServletRequest. So a request-based impl needs a cast and degrades for non-servlet requests.
2. No request in the motivating use case. VaadinRequest.getCurrent() is null in background threads, and UI.access explicitly does not populate it (UI.java:572: "VaadinService#getCurrentRequest() … will not be defined"; VaadinService.runPendingAccessTasks does CurrentInstance.clearAll(); setCurrent(session)). Flow itself uses this as its background-thread detector (Effect.java:276). "Email a link" is very often exactly that context — so a naive getAbsoluteUrl() reading the current request would throw precisely where it's needed most. Nothing caches the request's base URL server-side today (requestURL is only pushed to the client, JavaScriptBootstrapHandler.java:174).

And a proxy caveat worth stating up front: Flow parses no Forwarded / X-Forwarded-* headers anywhere (the only X-Forwarded-For reads are dev-tools host allow-listing and DAU remote-address). Whatever we add would be only as proxy-correct as the container/ForwardedHeaderFilter configuration (server.forward-headers-strategy). That's a documentation obligation, not a blocker, but it does mean we'd be handing users a footgun that the current relative-URL design doesn't have.

Options

A — Expose the base URL, keep RouteConfiguration request-free. Add a public API for the absolute application/service root, e.g. VaadinService.getApplicationBaseUrl(VaadinRequest) (essentially promoting VaadinServlet.getApplicationUrl), and let callers do base + config.getUrl(target, params). Smallest API surface; no request-dependency smuggled into a class with an forApplicationScope() factory; one obvious place to document the proxy caveat. Still request-scoped only.

B — RouteConfiguration.getAbsoluteUrl(Class, …) overloads, resolving the base from VaadinRequest.getCurrent(). Exactly what the issue asks for and the nicest call site, but it makes a request-free class request-dependent, needs defined behaviour when there is no request (throw? Optional?), and fails in background threads.

C — Cache/configure the base URL so absolute URLs also work under ui.access: capture the bootstrap request's base on the VaadinSession, and/or add an explicit deployment property (vaadin.baseUrl / external URL) that wins over request reconstruction. This is the only option that actually serves the emailing-from-a-background-thread case. It's also the largest: session-caching a host derived from an untrusted Host header needs an explicit-config-first policy to avoid host-header injection into outbound links.

Recommendation

A now, plus the explicit-configuration half of C (a configured external base URL taking precedence over request reconstruction), then B on top as sugar once the base-URL semantics are settled. I'd rather not ship B alone: its convenience is precisely where its failure mode is.

I'm deliberately not opening a PR — this is an API addition with a proxy/security policy attached, so it wants a maintainer decision on which option (and on Optional vs. throwing, and whether the base includes the servlet mapping) rather than a guess from me.

2. Licensing — real, but not a Flow issue

The licence checker isn't in this repo. com.vaadin:license-checker is an external artifact (pinned in /pom.xml:236, <scope>provided</scope> in flow-server/pom.xml:63, package com.vaadin.pro.licensechecker). Flow only has call sites: BaseLicenseCheckerServiceInitListener (dev-mode only, marked internal, product name/version passed in by subclasses — no constants here), IndexHtmlRequestHandler.addLicenseChecker (:391, injects the no-op maybeCheck and collects cvdlName from element constructors), plus dev-tools and build-plugin paths. There is no isValidLicense in this repo, and no product-identifier registry.

So both asks land elsewhere: isValidLicense's "unknown product name == valid" behaviour is a license-checker change, and a component-level isLicensed() or documented product identifier is a component/platform change (the cvdlName already exists on the web component side, which is arguably the identifier that should be documented). Flow could at most surface what it already collects.

Suggestion: split this issue. Keep 1 here as the RouteConfiguration absolute-URL API request, and refile 2 against license-checker/platform — otherwise neither half can be triaged or closed independently.

[manolo]

Split, as suggested. The licensing half is now vaadin/license-checker#119 and this issue is only part 1, the absolute route URL.

Two things came out of moving it that were not in the original report, and both are measured rather than read:

isValidLicense does not ignore only unknown product names, it ignores the argument entirely. On one machine, with a valid Pro key, vaadin-grid-pro, vaadin-charts, vaadin-core, a name that is not a product and the empty string all answer true; with the key hidden, the same five all answer false. So it reports whether the machine has a key, and never anything about the product. There is a small project on the new issue that prints both runs.

And the second ask, a component level isLicensed() or a documented product identifier, is not for the license checker either, for the reason your comment gives: cvdlName lives on the web component. That one is left unfiled and named at the bottom of the new issue, so it does not disappear, rather than being bundled a second time.

Nothing to do here beyond the title, which still says "two server side gaps". Happy to retitle it if that helps triage.

[mshabarov]

The absolute URL can be generated in UI bootstrap and stored, because it then doesn't change.