Cross-Origin-Resource-Policy: same-origin header breaks RSS in Thunderbird
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
People
(Reporter: hanno, Unassigned)
Details
I recently enabled several new security headers that are supposed to protect against spectre attacks on my personal webpages. Shortly after that I got a report that my RSS feed stopped working in Thunderbird.
I figured out this was due to the Cross-Origin-Resource-Policy header (set to same-origin in my case).
I disabled it on my own webpage, but created a test case here to reproduce:
https://rss.q2.re/rss.rss
If you try to add this as a feed to Thunderbird it will say: "The feed URL could not be found. Please check the name and try again."
The feed system uses standard xhr to get the xml feed file from your site; an obscure gecko level errorCode (translated as unreachable) is passed up and results in the "could not be found" print.
Do you think the feed request should override xhr in some way for cors so gecko doesn't fail it? What I mean is: why do you think you need to set same-origin for your feed file? (It may or may not be valid to do so, and it may be a lower level bug, given it's xml that is being requested; it might be interesting to see how fetch() would handle it).
(In reply to alta88 from comment #1)
... override xhr in some way for cors so gecko doesn't fail it ...
Setting mozAnon and mozSystem on the xhr request will likely do it, in case someone wants to do a patch.
|
||
Comment 3•4 years ago
|
||
I currently have the same issue with https://portswigger.net/daily-swig/rss, download of this feed fails due to cross-origin-resource-policy: same-origin header. Channel status is 0x8053040c meaning NS_ERROR_DOM_CORP_FAILED. I already tried mozAnon and mozSystem, neither has an effect here.
Looking at the source code, this issue has been addressed in bug 1703464 which landed on 89 branch. Maybe it can be backported to 78 branch?
Description
•