-
lovetox
hm i have a server that answers to my stream initiation with a whitespace
-
lovetox
do i have to ignore that, or can i expect a stream initiation in return
-
zinid
lovetox, what do you mean? just a single whitespace without the stream header?
-
lovetox
yes
-
lovetox
actually its a ejabberd, but its configured so the connection is proxied over nginx
-
lovetox
the user said he already asked in ejabberd support
-
lovetox
technically whitespaces between xml elements should not be a problem, its just weird that on calling recv() i get only a whitespace
-
lovetox
i dont know what happens then because at that point Gajim aborts, because in stream initiation it expects the streamheader on the first recv()
-
lovetox
looks like that
-
lovetox
https://paste.gajim.org/view/d68787ba
-
flow
lovetox, IIRC the RFC explicitly states that you need to expect whitespaces
-
flow
https://tools.ietf.org/html/rfc6120#section-11.7
-
lovetox
hm that says "between" xml elements
-
lovetox
could be argued that this does not count for the initial stream opening
-
flow
isn't it between elements
-
flow
because there is no preceeding element?
-
lovetox
yeah, its the response to my stream opening
-
flow
and it's the very first stream opening?
-
lovetox
yes
-
lovetox
see my paste
-
Kev
"Gajim aborts, because in stream initiation it expects the streamheader on the first recv()" That's certainly not valid, there's no guarantee that you'll receive the whole header at once.
-
Kev
Even without whitespace oddities.
-
flow
but anyhow I wouldn't be so pedantic in this case and simply take care of the whitespace
-
lovetox
yeah of course, its just weird, there is really no need to send only a whitespace
-
flow
and, as Kev correctly points out, you have to be able to reassemble the XML open tag (or later elements) from multiple recv calls
-
flow
yep, I am curious to hear the backstory behind that whitespace
-
lovetox
yeah thats no problem, if there is actually an open tag
-
lovetox
probably misconfigured stuff somewhere, but anyway i have to deal with it :/
-
Kev
Without checking the specs, I remember something about whitespace not being valid at the top level, but I might misremember.
-
lovetox
Kev, no should be valid at top level
-
lovetox
just not in tls and sasl negotiation
-
Kev
I'm certainly not in a position to argue with that :)
-
lovetox
i just read the section flow posted ^^
-
Kev
I missed that. It's still early :)
-
Alex
in the very old days some clients sent a whitespace after upgrade to tls, because some SSL libs were not upgrading to tls without a flush
-
lovetox
ok the backstory is a nginx that runs on 5222 and only support directls and expects SNI hostname set
-
lovetox
and if you connect plain there, it just sends you endless whitespace because it cant route the traffic to the xmpp server
-
lovetox
how needs srv set so a server only support directtls?
-
lovetox
only setting xmpps-client?
-
Zash
and _xmpp-client in srv 0 0 0 .
-
Zash
probably
-
Alex
the spec sais that xmpps is the preference
-
Alex
``` STARTTLS MUST NOT be used over direct TLS connections. ```
-
zinid
lovetox, there is no way to support directtls only I guess, because a client will fallback to A address with starttls anyways
-
lovetox
hm just not answering on port 5222 is a start i guess
-
lovetox
only answer on 5223 which should be a direct tls port
-
zinid
yes, this will work as long as a client supports directtls and _xmpps-client records
-
Alex
yes, many clients still don't support them
-
Alex
let's force them to upgrade 😜
-
lovetox
obviously this is not a generic public open server
-
Link Mauve
zinid, you shouldn’t fallback if your SRV points to . like Zash said.
-
zinid
ah
-
lovetox
yeah Gajim also doesnt do a fallback
-
lovetox
only fallback is xmpps to xmpp
-
lovetox
and if no srv entrys are available whatsoever
-
lovetox
5223 to 5222