feat: migrate to the Mercure 1.0 protocol - #8
Open
BySplashGm wants to merge 2 commits into
Open
Conversation
BySplashGm
marked this pull request as ready for review
September 4, 2026 13:28
Member
|
can you rebase this one ? |
BySplashGm
force-pushed
the
feat/mercure-1.0
branch
from
September 8, 2026 14:08
16827a0 to
f9b884c
Compare
Member
|
Can we split the basic 1.0 compatibility and the new shared-pattern change? I'm not sure we need such behavior in this low-level component. |
Test server now runs mercure/caddy v1.0.0-alpha.3. The 2.8 builder ships Go 1.23.4 and cannot build it (requires go >= 1.26), so the builder moves to 2.11.4 — the Caddy version mercure/caddy pins — and both plugins are pinned explicitly: unpinned, xcaddy resolved mercure/caddy to the latest stable tag and silently gave 0.24.2. Caddyfile ported to modern mode, directive for directive: flag-form anonymous, `debugger` for the renamed `ui`, and an issuer block replacing the flat publisher_jwt/subscriber_jwt, which now work only under protocol_version_compatibility. resource_identifier is set because an identifier ending in /.well-known/mercure also becomes the base URL relative topics resolve against, and the topics here are rel="self" link values. Client subscribes with `match` instead of the removed `topic` parameter. The tracked topics are those same relative link values, so the exact matcher is the right semantics; match_urlpattern is not exposed yet. Publisher fixtures reminted as RFC 9068 access tokens: typ at+jwt, iss, aud, exp and authorization_details. The legacy `mercure` claim and typ JWT are both rejected in modern mode.
Every listen() opens a fresh connection, so the id of the last update has to travel with the request. The client only set the Last-Event-Id header, which a native EventSource cannot do — resuming worked solely because of the npm eventsource polyfill, even though the README invites callers to pass their own EventSource. The spec is explicit that the hub "MUST then take the union" of the query and body components and that this "applies to the topic matcher parameters and to last_event_id ... alike", so the cursor now goes in the query too. The header is still sent, for implementations that support it.
BySplashGm
force-pushed
the
feat/mercure-1.0
branch
from
September 8, 2026 15:16
f9b884c to
aa5e68f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes this repository work against the Mercure 1.0 protocol.
Hub
caddy:2.8-builderships Go 1.23.4 and cannot buildmercure/caddy@v1.0.0-alpha.3(
requires go >= 1.26), so the builder moves to 2.11.4 — the Caddy version Mercurepins — and both plugins are now pinned explicitly. Unpinned,
xcaddyresolvedmercure/caddyto the latest stable tag and silently gave 0.24.2.The
mercureblock is ported directive for directive: flag-formanonymous(
anonymous trueis now rejected withunknown mercure directive "true"),debuggerfor the renamedui, and anissuerblock replacing the flatpublisher_jwt/subscriber_jwt, which in 1.0 work only underprotocol_version_compatibility.resource_identifieris set deliberately: anidentifier ending in
/.well-known/mercurealso becomes the base URL that relativetopics resolve against, and the topics here are
rel="self"link values.Client
?topic=is gone; subscriptions are sent asmatch(exact).match_urlpatternis not exposed from
@api-platform/mercureyet — that's a separate PR, since it'sworth discussing on its own whether that decision belongs in this low-level client.
The resume cursor is also now sent as a
last_event_idquery parameter, not justthe
Last-Event-Idheader: everylisten()opens a fresh connection, so the id hasto travel with the request, and a native
EventSourcecannot set headers. The specrequires the hub to take the union of the query and body components, applying
"alike" to the topic matcher parameters and to
last_event_id. The header is stillsent, for implementations that support it.
Tokens
The publisher fixtures are reminted as RFC 9068 access tokens (
typ: at+jwt,iss,aud,exp,authorization_details). The legacy{"mercure": {...}}claim and atypofJWTare both rejected in modern mode.Tests
tests/mercure.spec.tsupdated for the new query parameter and token shape.Verification. Run against a
v1.0.0-alpha.3hub.