Root cause
The Notifications Macro's "RSS Feed" link points at the REST endpoint /rest/notifications/rss (built in NotificationsMacro.xml:1171-1187), which is served by NotificationsResource.getNotificationsRSS(...). That method returns a bare String (the RSS 2.0 document from Rome's SyndFeedOutput) and declares no
@Produces.
With no @Produces, the JAX-RS runtime negotiates the response media type from the browser's Accept header — which for a normal navigation is text/html,.... So the feed is sent as text/html, and the browser renders the RSS markup as HTML: the <rss>/<channel>/<item> tags are swallowed and only text nodes + escaped
inner-HTML remain. That's exactly the Firefox screenshot. Chrome's "RSS Subscription Extension" sniffs the body so it still renders it — which is why it's Firefox-only in the report.
This is a different code path from XWIKI-24528 (which Simon just fixed): that was the Notifications Menu, served by the NotificationRSSService wiki page. Same feature, two independent feeds — which fits Simon's note that they were reported together.
When the regression was introduced: XWiki 16.2.0
getNotificationsRSS never had a @Produces. Under the old Restlet REST stack a bare String was served as XML; the Restlet→Jersey migration (XWIKI-12674 / XWIKI-12955, commit 8a7283f5dfe, 2024-02-26) changed the default so a bare String is content-negotiated to text/html for browsers. First release tag containing
it: xwiki-platform-16.2.0. (Confirmation trail: the commented-out MediaType.APPLICATION_RSS entries in PreMatchingRequestFilter are Restlet-era leftovers from that same migration.)
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
