Feed fetch error: unable to fetch: 0 [200]

Tiny Tiny RSS Support
1

Describe the problem you’re having:
Feed fetch returning error “unable to fetch: 0 [200]”

If possible include steps to reproduce the problem:
I’m cannot reproduce externally, have tested with fakecake

tt-rss version (including git commit id):
Tiny Tiny RSS v17.12 (fdde115)

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
‪Ubuntu 14.04.5 LTS‬, PHP 7.0.27, PostgreSQL 9.6.6, curl 7.35.0

Please provide any additional information below:

After a recent upgrade to the latest TTRSS version and as well a switch from PHP5 to PHP7 I’m experiencing this error on about 10 out of 2000 or so feeds. I’m fairly sure they all worked before the update and the error is not telling me too much. My open_basedir is set to “nothing” and I found this on the old forum ht tps://tt-rss.org/oldforum/viewtopic.php?f=1&t=3775&p=22406&hilit=unable+to+fetch%3A+0#p22406 that is similar but I believe all feeds failed in that acse and not just a small percent as I’m seeing.

Example site:

[13:53:36/30384] start
[13:53:36/30384] local cache will not be used for this feed
[13:53:36/30384] last unconditional update request: 2018-01-29 12:31:59
[13:53:36/30384] stored last modified for conditional request: Mon, 29 Jan 2018 12:07:44 GMT
[13:53:36/30384] fetching [ht tps://www.geek4you.it/feed/] (force_refetch: )...
[13:53:37/30384] fetch done.
[13:53:37/30384] source last modified: Mon, 29 Jan 2018 12:07:44 GMT
[13:53:37/30384] unable to fetch: 0  [200]

I tested this feed on feedcake and works fine, so my first thought was that it was linked to my servers PHP version, though reverting back to the previous PHP5 version gives me the same error. Note that access the feed a browser and tiny proxy running the same box.

A CURL test for reference:

curl -IL ht tps://www.geek4you.it/feed/
HTTP/1.1 200 OK
Date: Mon, 29 Jan 2018 14:29:33 GMT
Content-Type: application/rss+xml; charset=UTF-8
Connection: keep-alive
Set-Cookie: __cfduid=dbbab9ce100fae4c42fe80c5020de26fd1517236173; expires=Tue, 29-Jan-19 14:29:33 GMT; path=/; domain=.geek4you.it; HttpOnly
Accept-Ranges: bytes
Alt-Svc: quic=":443"; ma=2592000; v="35,37,38,39"
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Cf-Railgun: direct (starting new WAN connection)
Etag: "1cc66b65e50ff9e3c3f58a52e93e80d8"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Last-Modified: Mon, 29 Jan 2018 12:07:44 GMT
Link: <ht tps://www.geek4you.it/wp-json/>; rel="ht tps://api.w.org/"
Pragma: no-cache
Set-Cookie: PHPSESSID=mk2r1fhg015cc9gnku4mpcieb3; path=/
Set-Cookie: vchideactivationmsg=1; expires=Fri, 29-Jan-2021 14:29:32 GMT; Max-Age=94694400; path=/
Set-Cookie: vchideactivationmsg_vc11=5.4.5; expires=Fri, 29-Jan-2021 14:29:32 GMT; Max-Age=94694400; path=/
Strict-Transport-Security: max-age=0; preload
X-Litespeed-Cache-Control: no-cache
X-Robots-Tag: noindex, follow
X-Turbo-Charged-By: LiteSpeed
X-Content-Type-Options: nosniff
Expect-CT: max-age=604800, report-uri="ht tps://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 3e4ce26158179c65-AMS

Ignore the space between “ht tp” as a hotfix for not beeing allow allowed to post more than two “links”

Any thoughts on my best next steps, not sure if TINY related or not at this point?

2

https://tt-rss.org/oldforum/viewtopic.php?f=1&t=3775&p=22406&hilit=unable+to+fetch%3A+0#p22406

also: search

e: probably not your problem though since you are only seeing this with a subset of feeds. hm.

3

Sorry, I already edited that link into my post as I’ve been googling and reading up on what I could find already (likely after you read my post).

Was that not a case of ALL FEEDS experiencing the issue and not 10 with 1990 working? Due to some program disabling CURL in essence? Not sure how that helps me on this one.

** EDIT to your response, exactly a subset so I don’t think they are related **

4

the most likely reason in your case is sadly cloudflare. not sure what you could do about it, short of contacting site owner and/or trying to change tt-rss user agent.

5

Hmmm, but your fakecake test platform should if so be exposed to the same issue right? Presumably, it uses the default user agent name … but it manages to get the feed somehow? Or am I missing something obvious?

EDIT 1:
Plus a regular CURL feedurl (no parameters) does output the whole feed from the server console, so yes could definitively be user agent, but confused as to why feedcake works if so.

EDIT 2:
Now I am even more confused, somehow TINY have managed to fetch the feed once this morning, though the debugger and the site still shows red with the same error. Checking up on the other feeds with this issue…

6

most likely the server in question rate limits (or uses any other criteria to) filter based by IP. since my feed tester didn’t previously access the feed you tried on it worked properly.

the only really sad part is that whoever designed all this couldn’t figure out http status codes which adds to the confusion, otherwise they are of course free to ban whoever they want, stupid and pointless it may be.

e: if you start accessing their site with curl UA they might ban it too. or not, you’ll never know until you try. :man_shrugging:

7

Fair enough; I’ll have to monitor this another day I think; I’ve just counted some 60 or so feeds with this error, some of which work again when I check them out (maybe I got more during the swap to php5 and back again earlier, not sure). Leaving PHP7 and the current configuration until it settles down and will check again tomorrow morning.

I’m not sold on rate limit yet; but keeping an open mind. Unless my old tiny version reported these differently it would be a mighty conscience to go from none of these errors to having 10-60 of them after upgrading I think.

Enjoy your evening fox, and “thank you” as always, if anyone else reads this and got some thoughts to share, feel free to jump in (I’ll update again this week once I’ve maybe figured something out).

8

btw you can also try setting update interval to a higher value, like once an hour.

9

Could some potential SSL/certifcate issues somehow be reported like this or would that give different messaging?

10

i’m pretty sure you won’t get a http 200 ok response in this case, and there’s going to be a ssl-related error. also i’m too lazy to look this up but error code 0 is likely “no error”. it’s just there’s, you know, no data returned.

11

I can’t explain it yet… but a force refresh in feed debug mode makes tiny update the feed (and remove the error 0). Still got a few left of the ones with error to fix like this and also not yet sure if this will last or just pop back up again once it fetches normally next time (we’ll know for sure soon enough).

Sidenote; I used to be able to double-click a feed entry for it to try to re-fetch, did that functionality get removed at one point or am I having another weird bug on my hands :slight_smile:

12

maybe this is related to http if-modified-since. there’s really not much difference with debug and normal feed updates tbh.

yep, that one got removed

13

Cheers, that explains then :slight_smile: So overnight I’m again seeing Error 0 on the 4-5 feeds I forced late yesterday of the 10 having this issue. I will take a second look at their entries in the database and what might relate to the http if-modified-since - maybe I can spot something that can close this case for me. I’ll also delete/re-create one and see what happens with it.

Edit: Re-created two of my trouble feeds and they turn up as ERROR 0 directly, so I presume in theory that means there’s nothing corrupt/wrong with select entries in the feeds table itself (a force refresh on the other hand of either reads the feed content, just not happening with a normal fetch).

14

Such a shame really. This was useful for sampling newly-subscribed feeds. Now I have to wait for the daemon’s next update cycle (15 min in my case).

15

there was too much bullshit with this feature

  • open_basedir in frontend but not backend? oops, can’t use curl plugins
  • image cache? can’t use it, would take too long and httpd will timeout
  • etc, etc, not worth it
16

Yeah, I take your word for it, fox. You know your stuff. And fD offers a workaround.

17

some kind of priority queue (with lower rescan interval) for never updated / manually requested feeds would probably work, idk

18

I noticed a while ago that the fr keyboard shortcut which used to refresh a feed no longer seemed to work. It’s related I guess? Just tested it again and yep, pressing fr makes it look like something is happening but the feed isn’t actually fetched. If the feature is removed shouldn’t the keyboard shortcut and help text in the menu also be removed?

19

refresh the view in the UI =/= force reload the feed from the source