Multipath TCP (MPTCP) for DiscourseHub and iOS Safari PWA behind Caddy

Product Support Self-hosting
, , , ,
2

Follow-up: interrupted iOS post edit and HTTP/3 connection continuity

I have now encountered a practical example of the connection-continuity problem I was asking about.

On 21 October 2026, while editing a post in my private Discourse instance on an iPhone 16 Pro using the Safari PWA, the blue Saving bar became stuck. I had just dictated some additional lecture notes.

The composer was no longer accessible, including when I touched the blue Saving bar, so I couldn’t copy the unsaved text elsewhere.

After waiting longer than usual, I manually disabled Wi-Fi to try cellular connectivity. The page did not immediately change, but subsequent attempts to navigate also appeared to hang.

I subsequently examined the Caddy and nginx logs and the post’s revision history.

At 12:20:08 BST:

  • Caddy recorded an HTTP/3 PUT /posts/70695 request from the university Wi-Fi connection, with all 1,000 request-body bytes received but status 0.

  • nginx recorded the corresponding request as HTTP 400, with no Discourse route or upstream processing time.

  • Two other iPhone requests originating from the cellular connection also received HTTP 400 at the same second.

  • No successful post revision was recorded at that time.

A subsequent edit succeeded at 12:20:55 BST, but the dictated text was missing.

There was also a successful Discourse draft autosave at 12:19:44 BST, although I cannot establish whether it contained the missing text.

I appreciate that manually disabling Wi-Fi may have interrupted outstanding requests. However, the original Saving operation was already stuck before I changed the network connection.

This raises two questions related to my original post:

  1. QUIC connection migration: Is there a recommended way of determining whether the iOS browser attempted migration of the existing HTTP/3 connection, rather than establishing a new connection or abandoning outstanding requests?

  2. Discourse composer recovery: If a post-edit request becomes stuck or is interrupted, is the composer expected to remain inaccessible behind the Saving state? Is there an existing timeout, retry or recovery mechanism that should preserve the unsaved text?

I’m particularly interested in the second question because I couldn’t return to the editor to copy my work before attempting to restore connectivity.

I haven’t changed any Caddy, nginx or HTTP/3 settings as a result of this incident, since the available evidence doesn’t yet identify what caused the initial Saving operation to stall.