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?
thomaslewishas left
Kevhas joined
msavoritiashas joined
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! 🙂
alhas joined
Millesimushas joined
Alexhas joined
antranigvhas left
jubalhhas joined
thomaslewishas joined
Millesimushas left
Millesimushas joined
Kevhas left
Kevhas joined
antranigvhas joined
antranigvhas left
thomaslewishas left
debaclehas joined
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
adxhas left
Millesimushas left
Millesimushas joined
raghavgururajanhas joined
thomaslewishas joined
alhas left
Millesimushas left
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>
Millesimushas joined
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>
Stefanhas joined
lovetoxsounds like a server bug or?
flowyou mean the server should send a stream open immediately followed by </stream>?
lovetoxi guess ..
thomaslewishas left
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/>?
lovetoxyeah ..
flowbasically the server just awaits commands from the client
lovetoxso actually, i need to reopen the stream, and end it afterwards
marchas joined
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
Millesimushas left
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
dezanthas left
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
flowright
Millesimushas joined
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
badrihippohas left
goffihas joined
lovetoxhmmmm i found the server who does this :D
lovetoxprosody bug report incoming :)
thomaslewishas joined
badrihippohas joined
lovetoxok maybe not
lovetoxdamn
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
jubalhhas left
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?
