jdev - 2022-05-27


  1. 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?

  2. flow

    badrihippo, that sounds about right, see also https://datatracker.ietf.org/doc/html/rfc6121#section-3.4

  3. badrihippo

    Ah that's what I was looking for; thank you! 🙂

  4. lovetox

    badrihippo, of course you need a server that actually supports that

  5. lovetox

    which is ot a given

  6. lovetox

    but i guess it doesnt hurt to just do it

  7. lovetox

    Question, after successful AUTH we are supposed to reset the stream

  8. lovetox

    what if i want to end the stream right after AUTH

  9. lovetox

    would i need to wait on the server reinitiating the stream with <stream:stream ...>

  10. lovetox

    then send it </stream:stream>

  11. lovetox

    currently i send </stream:stream> instantly after i recieve the <success> from the auth

  12. lovetox

    the server responds to that with a </stream:stream>

  13. lovetox

    which i parser rejects because the server never reinitiated the stream after <success>

  14. lovetox

    sounds like a server bug or?

  15. flow

    you mean the server should send a stream open immediately followed by </stream>?

  16. lovetox

    i guess ..

  17. lovetox

    im not sure how the server even can send </stream> first

  18. lovetox

    i mean would a server not queue up the stream open instantly after sending <success>

  19. lovetox

    what is he waiting for ?

  20. lovetox

    or is he waiting for my client?

  21. lovetox

    am i supposed to open the stream and server reacts to that with a open himself

  22. 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/>?

  23. lovetox

    yeah ..

  24. flow

    basically the server just awaits commands from the client

  25. lovetox

    so actually, i need to reopen the stream, and end it afterwards

  26. flow

    and in your case, your client sends </stream> instead of a new stream open tag

  27. lovetox

    or i simply dont reopen, but also dont reset the parser

  28. lovetox

    ok, thanks flow that helped

  29. flow

    I think you want to reset your parser only after you send a new stream open tag

  30. lovetox

    # Reset parser because we will receive a new stream header # which will otherwise lead to a parsing error

  31. lovetox

    thats my comment, so i guess some servers do indeed send out stream reopen

  32. 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

  33. lovetox

    and not wait for the client

  34. lovetox

    but then this would be a server bug, because client opens streams not servers

  35. flow

    hmm servers sending stream open unsolicited would probably be a server bug

  36. lovetox

    i guess its the expected thing after auth, so maybe server dev thought not to wait for client

  37. lovetox

    but yeah they should not do this

  38. flow

    right

  39. badrihippo

    lovetox: I'm running the server, so that's not an issue 🙂

  40. badrihippo

    The standard says not to do it unless the server supports it though (duh) so I'll try to check for that firstn

  41. badrihippo

    The standard says not to do it unless the server supports it though (duh) so I'll try to check for that first

  42. lovetox

    thats what i meant

  43. lovetox

    i just remember some servers did just not implement that

  44. lovetox

    hmmmm i found the server who does this :D

  45. lovetox

    prosody bug report incoming :)

  46. lovetox

    ok maybe not

  47. lovetox

    damn

  48. 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).

  49. 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).

  50. lovetox

    so im not allowed to end the stream

  51. lovetox

    i need to reopen it, just to end it

  52. lovetox

    or i simply do nothing

  53. lovetox

    if i dont reopen i also dont need to close ..

  54. lovetox

    but maybe its better to open and then to close, otherwise the server might have some resource handing around?

  55. lovetox

    https://share.hoerist.com/philipp/Mam1fIoti0xJnAZe/rfc.jpg

  56. flow

    lovetox, I forgot to ask previously: in which situation do you want to close the stream after the SASL auth was successful?

  57. lovetox

    I only want to test that account credentials input by the user are correct

  58. lovetox

    I have this as a precondition before adding the account with all settings dB tables etc to gajim

  59. 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

  60. lovetox

    Also I want to give the user an option to add the account without connecting yet