Unsuccessful connection to Pleroma instance(s)

Last edit

Summary: Closed

Changed:

< Tags: [[tag:Issue]] [[tag:Bitlbee Mastodon]] [[tag:Open]]

to

> Tags: [[tag:Issue]] [[tag:Bitlbee Mastodon]] [[tag:Closed]]


The initial OAuth and connection works fine but then there's a "200 OK (Stream Closed)" reply from Pleroma (caught in mastodon_http_stream) which forces a logout.

Unfortunately, because we have an existing access token, the plugin tries to get a refresh token which it looks like Pleroma doesn't support (bizarrely) and consequently the login attempt will always fail.

(Disabling the refresh token step means I can stay logged in but then something happens every 2 minutes which results in a logout anyway.)

Tags: Closed

Reopen issue

Comments

Last edit

Summary: Still interesting. :)

Added:

> ----
> Still interesting. :)
> -- Alex Schroeder 2018-12-04 22:39 UTC


Happy to provide account(s) on my Pleroma instance if that helps in any way.

– zimpenfish 2018-12-03 21:15 UTC


I wonder why the stream closes. That seems to be the root cause of the problem, right?

– Alex 2018-12-04 08:26 UTC


Had a look at the Bitlbee code and it's setting HTTPC_EOF because req->body_size >= req->content_length (which seems to mean "I've read all the content"). Fixing* that (by not setting HTTPC_EOF in that instance) just leads to bitlbee crashing in send_keepalive instead. Swapping from nginx as a proxy to pound doesn't help, then it just crashes in http_free instead.

In summary, I think this might be more of a Bitlbee issue than a bitlbee-mastodon issue.

– zimpenfish 2018-12-04 10:18 UTC


Hm. Or it's a problem that can be fixed in Pleroma? I wonder what the content length is supposed to be – and what Mastodon uses?

– Alex 2018-12-04 10:51 UTC


Interesting/Bizarrely, connecting to a real Mastodon instance (octodon.social) has the HTTP code setting HTTPC_EOF because c==CR_EOF which somehow doesn't make it intact to mastodon_http_stream (and thus everything works happily.) It may be less of a Bitlbee problem and more of a Erlang/Elixir/Phoenix problem.

– zimpenfish 2018-12-04 11:49 UTC


Mastodon sends no Content-Length and Transfer-Encoding: chunked (hence why it doesn't trigger the body_size > content_length EOF).

Pleroma sends Content-Length and no Transfer-Encoding.

Is it even possible to work around this difference in the Bitlbee/bitlbee-mastodon code?

– zimpenfish 2018-12-04 11:55 UTC


I don't think so. I guess I'm trying to figure out whether Pleroma is doing it wrong. Is this something that should go upstream to Pleroma or Bitlbee?

– Alex 2018-12-04 12:01 UTC


As far as I can tell, it's (indirectly) Pleroma - they use Phoenix as their web layer which doesn't mention chunked anywhere in their source. Which is annoying because Phoenix uses Plug which -does- support sending chunked (but only if you explicitly enable it.)

I think this can probably be closed for now - it definitely seems to be outside of bitlbee-mastodon for the moment. Apologies!

– zimpenfish 2018-12-04 12:36 UTC


Still interesting. :)

– Alex Schroeder 2018-12-04 22:39 UTC


This wiki uses a variant of Markdown.

To save this page you must answer this question:

Please write "new issue" into the field below.