i was hoping we could keep CurlHttpClient cleanly separated by treating it as a thirdparty http client

this change removes the http user agent for non-curl-impersonator usage which might break some fetching. (default ua is Curl v1.2.3 or simply the empty string i dont remember)

this change breaks the usage of custom http headers for non-curl-impersonate uses (no it doesnt, i read code wrong)

i was hoping we could keep CurlHttpClient cleanly separated by treating it as a thirdparty http client

I can see that, but you could also make a point that getContents() in contents.php could be kept clean of the actual underlying anti-bot measures, which is the purpose of the default headers you had there already.

Also, I would imagine any alternative client would need to incorporate some of their own anti-bot measures, possibly with another set of headers, so if we consider the current set of default headers as curl-specific, I think it makes sense to keep them all sealed off in CurlHttpClient.

It would be hard to fix the libcurl-impersonate usage without the refactoring I did.

this change removes the http user agent for non-curl-impersonator usage which might break some fetching. (default ua is Curl v1.2.3 or simply the empty string i dont remember)

Indeed, fixed it.

thanks for helping to keep this up to date.

@dvikan I found by accident that https://github.com/RSS-Bridge/rss-bridge/blob/master/bridges/FB2Bridge.php reads the useragent value from configuration and uses that to issue a file_get_contents() call . I believe the bridge might be failing now because the useragent config value is now empty by default.

I don't know why file_get_contents is used here. From what I gathered, that function does not use curl internally, IMHO it should be rewritten to use CurlHttpClient.

yes file_get_contents should not be used. Im considering deleting this bridge. But im unsure if it works or is in use.

dont worry about it, I will check whether the bridge works or not