badrihippoNewbie 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?
flowbadrihippo, that sounds about right, see also https://datatracker.ietf.org/doc/html/rfc6121#section-3.4
badrihippoAh that's what I was looking for; thank you! 🙂
lovetoxbadrihippo, of course you need a server that actually supports that
lovetoxwhich is ot a given
lovetoxbut i guess it doesnt hurt to just do it
lovetoxQuestion, after successful AUTH we are supposed to reset the stream
lovetoxwhat if i want to end the stream right after AUTH
lovetoxwould i need to wait on the server reinitiating the stream with <stream:stream ...>
lovetoxthen send it </stream:stream>
lovetoxcurrently i send </stream:stream> instantly after i recieve the <success> from the auth
lovetoxthe server responds to that with a </stream:stream>
lovetoxwhich i parser rejects because the server never reinitiated the stream after <success>
lovetoxsounds like a server bug or?
flowyou mean the server should send a stream open immediately followed by </stream>?
lovetoxi guess ..
lovetoxim not sure how the server even can send </stream> first
lovetoxi mean would a server not queue up the stream open instantly after sending <success>
lovetoxwhat is he waiting for ?
lovetoxor is he waiting for my client?
lovetoxam i supposed to open the stream and server reacts to that with a open himself
flowlovetox, "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/>?
flowbasically the server just awaits commands from the client
lovetoxso actually, i need to reopen the stream, and end it afterwards
flowand in your case, your client sends </stream> instead of a new stream open tag
lovetoxor i simply dont reopen, but also dont reset the parser
lovetoxok, thanks flow that helped
flowI 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
lovetoxthats my comment, so i guess some servers do indeed send out stream reopen
flowwell 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
lovetoxand not wait for the client
lovetoxbut then this would be a server bug, because client opens streams not servers
flowhmm servers sending stream open unsolicited would probably be a server bug
lovetoxi guess its the expected thing after auth, so maybe server dev thought not to wait for client
lovetoxbut yeah they should not do this
badrihippolovetox: I'm running the server, so that's not an issue 🙂
badrihippoThe standard says not to do it unless the server supports it though (duh) so I'll try to check for that firstn✎
badrihippoThe standard says not to do it unless the server supports it though (duh) so I'll try to check for that first ✏
lovetoxthats what i meant
lovetoxi just remember some servers did just not implement that
lovetoxhmmmm i found the server who does this :D
lovetoxprosody bug report incoming :)
lovetoxok maybe not
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). ✏
lovetoxso im not allowed to end the stream
lovetoxi need to reopen it, just to end it
lovetoxor i simply do nothing
lovetoxif i dont reopen i also dont need to close ..
lovetoxbut maybe its better to open and then to close, otherwise the server might have some resource handing around?