jdev - 2019-11-10

hm i have a server that answers to my stream initiation with a whitespace

do i have to ignore that, or can i expect a stream initiation in return

lovetox, what do you mean? just a single whitespace without the stream header?

yes

actually its a ejabberd, but its configured so the connection is proxied over nginx

the user said he already asked in ejabberd support

technically whitespaces between xml elements should not be a problem, its just weird that on calling recv() i get only a whitespace

i dont know what happens then because at that point Gajim aborts, because in stream initiation it expects the streamheader on the first recv()

looks like that

https://paste.gajim.org/view/d68787ba

lovetox, IIRC the RFC explicitly states that you need to expect whitespaces

https://tools.ietf.org/html/rfc6120#section-11.7

hm that says "between" xml elements

could be argued that this does not count for the initial stream opening

isn't it between elements

because there is no preceeding element?

yeah, its the response to my stream opening

and it's the very first stream opening?

yes

see my paste

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

Even without whitespace oddities.

but anyhow I wouldn't be so pedantic in this case and simply take care of the whitespace

yeah of course, its just weird, there is really no need to send only a whitespace

and, as Kev correctly points out, you have to be able to reassemble the XML open tag (or later elements) from multiple recv calls

yep, I am curious to hear the backstory behind that whitespace

yeah thats no problem, if there is actually an open tag

probably misconfigured stuff somewhere, but anyway i have to deal with it :/

Without checking the specs, I remember something about whitespace not being valid at the top level, but I might misremember.

Kev, no should be valid at top level

just not in tls and sasl negotiation

I'm certainly not in a position to argue with that :)

i just read the section flow posted ^^

I missed that. It's still early :)

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

ok the backstory is a nginx that runs on 5222 and only support directls and expects SNI hostname set

and if you connect plain there, it just sends you endless whitespace because it cant route the traffic to the xmpp server

how needs srv set so a server only support directtls?

only setting xmpps-client?

and _xmpp-client in srv 0 0 0 .

probably

the spec sais that xmpps is the preference

``` STARTTLS MUST NOT be used over direct TLS connections. ```

lovetox, there is no way to support directtls only I guess, because a client will fallback to A address with starttls anyways

hm just not answering on port 5222 is a start i guess

only answer on 5223 which should be a direct tls port

yes, this will work as long as a client supports directtls and _xmpps-client records

yes, many clients still don't support them

let's force them to upgrade 😜

obviously this is not a generic public open server

zinid, you shouldn’t fallback if your SRV points to . like Zash said.

ah

yeah Gajim also doesnt do a fallback

only fallback is xmpps to xmpp

and if no srv entrys are available whatsoever

5223 to 5222