-
badrihippo
Newbie question: how does "pre-emptively grant subscription requests" work? Do I just send a `<presence type="subscribed">` to the contact or are there other subtleties?
-
flow
badrihippo, that sounds about right, see also https://datatracker.ietf.org/doc/html/rfc6121#section-3.4
-
badrihippo
Ah that's what I was looking for; thank you! 🙂
-
lovetox
badrihippo, of course you need a server that actually supports that
-
lovetox
which is ot a given
-
lovetox
but i guess it doesnt hurt to just do it
-
lovetox
Question, after successful AUTH we are supposed to reset the stream
-
lovetox
what if i want to end the stream right after AUTH
-
lovetox
would i need to wait on the server reinitiating the stream with <stream:stream ...>
-
lovetox
then send it </stream:stream>
-
lovetox
currently i send </stream:stream> instantly after i recieve the <success> from the auth
-
lovetox
the server responds to that with a </stream:stream>
-
lovetox
which i parser rejects because the server never reinitiated the stream after <success>
-
lovetox
sounds like a server bug or?
-
flow
you mean the server should send a stream open immediately followed by </stream>?
-
lovetox
i guess ..
-
lovetox
im not sure how the server even can send </stream> first
-
lovetox
i mean would a server not queue up the stream open instantly after sending <success>
-
lovetox
what is he waiting for ?
-
lovetox
or is he waiting for my client?
-
lovetox
am i supposed to open the stream and server reacts to that with a open himself
-
flow
lovetox, "would i need to wait on the server reinitiating the stream with <stream:stream ...>" does the server wait for the client to send the next stream open after <success/>?
-
lovetox
yeah ..
-
flow
basically the server just awaits commands from the client
-
lovetox
so actually, i need to reopen the stream, and end it afterwards
-
flow
and in your case, your client sends </stream> instead of a new stream open tag
-
lovetox
or i simply dont reopen, but also dont reset the parser
-
lovetox
ok, thanks flow that helped
-
flow
I think you want to reset your parser only after you send a new stream open tag
-
lovetox
# Reset parser because we will receive a new stream header # which will otherwise lead to a parsing error
-
lovetox
thats my comment, so i guess some servers do indeed send out stream reopen
-
flow
well actually before you send the stream open tag, as otherwise this could be racy, but definelty only reset the parser if your logic decided that it will send a new stream open tag
-
lovetox
and not wait for the client
-
lovetox
but then this would be a server bug, because client opens streams not servers
-
flow
hmm servers sending stream open unsolicited would probably be a server bug
-
lovetox
i guess its the expected thing after auth, so maybe server dev thought not to wait for client
-
lovetox
but yeah they should not do this
-
flow
right
-
badrihippo
lovetox: I'm running the server, so that's not an issue 🙂
-
badrihippo
The standard says not to do it unless the server supports it though (duh) so I'll try to check for that firstn✎ -
badrihippo
The standard says not to do it unless the server supports it though (duh) so I'll try to check for that first ✏
-
lovetox
thats what i meant
-
lovetox
i just remember some servers did just not implement that
-
lovetox
hmmmm i found the server who does this :D
-
lovetox
prosody bug report incoming :)
-
lovetox
ok maybe not
-
lovetox
damn
-
lovetox
> Upon receiving the <success/> element, the initiating entity MUST initiate a new stream over the existing TCP connection by sending a new initial stream header to the receiving entity (as specified under Section 4.3.3, the initiating entity MUST NOT send a closing </stream> tag before sending the new initial stream header, since the receiving entity and initiating entity MUST consider the original stream to be replaced upon success of the SASL negotiation).✎ -
lovetox
> Upon receiving the <success/> element, the initiating entity MUST initiate a new stream over the existing TCP connection by sending a new initial stream header to the receiving entity (as specified under Section 4.3.3, the initiating entity MUST NOT send a closing </stream> tag before sending the new initial stream header, since the receiving entity and initiating entity MUST consider the original stream to be replaced upon success of the SASL negotiation). ✏
-
lovetox
so im not allowed to end the stream
-
lovetox
i need to reopen it, just to end it
-
lovetox
or i simply do nothing
-
lovetox
if i dont reopen i also dont need to close ..
-
lovetox
but maybe its better to open and then to close, otherwise the server might have some resource handing around?
-
lovetox
https://share.hoerist.com/philipp/Mam1fIoti0xJnAZe/rfc.jpg
-
flow
lovetox, I forgot to ask previously: in which situation do you want to close the stream after the SASL auth was successful?
-
lovetox
I only want to test that account credentials input by the user are correct
-
lovetox
I have this as a precondition before adding the account with all settings dB tables etc to gajim
-
flow
I see, makes sense. So yeah, with the spec part you dugged out, it appears you have to restart the stream to end the stream
-
lovetox
Also I want to give the user an option to add the account without connecting yet