Ejabberd: BOSH + Large Stanza issue

[kpbg]

Long story short -- due to an issue with Ejabberd + using multiple SSL certificated, I had to upgrade to the latest version. The issue got solved, but new random things started to appear.

The biggest new issue is some large Stanzas doesn't want to go through.

If I cut the large string by 2500 characters, it will be processed properly.

It is really buzzing that I get a straight HTML response (< h1 >Bad Request< /h1 >) instead of an XML one. This is probably the reason for the instant disconnect upon sending the Stanza.

If I send the same long string through our backend, it works well. I have been comparing the strings and they are pretty much the same. I.e., the problem is only with the BOSH.

To reproduce the issue, use Strophe and run the following code:

var stanza = $iq({ type: 'get', id: 'extendSession', to: '[email protected]/xmpp', from: connection.jid }).c('query', {xmlns: 'jabber:iq:auth'}).c('resource','extendSession').up().c('token','x'.repeat(6000));
connection.sendIQ(stanza.tree(), function(cb){ console.log('CALLBACK:'); console.log(cb) }, function(cberr){ console.log('ERROR');console.log(cberr) }, 15000)

[mremond]

What is the size of the stanza ?

[kpbg]

6227 characters

It is generated this way:
var stanza = $iq({ type: 'get', id: 'extendSession', to: '[email protected]/xxxxxxx', from: connection.jid }).c('query', {xmlns: 'jabber:iq:auth', resource: 'extendSession' }, 'x'.repeat(6000));

However, if I use let say 3000 X-es instead of 6000, then it works.

In the debug log, I'm seeing the bad request coming empty:
2019-02-19 18:04:41.955 [debug] <0.6972.90>@ejabberd_http:process_header:307 ({tlssock,#Port<0.248533>,#Ref<0.3748348400.3760324612.86406>}) http query: 'POST' <<"/http-bind">>
2019-02-19 18:04:41.956 [debug] <0.6972.90>@ejabberd_http:process:394 [<<"http-bind">>] matches [<<"http-bind">>]
2019-02-19 18:04:41.956 [debug] <0.6972.90>@mod_bosh:process:63 Bad Request: no data

My max_stanza_size is 131072

P.S. the 6000 request works if I don't use BOSH

[prefiks]

So i don't have problems with 6k request, i think limit that you will hit is 64k that routine used for xml parsing by bosh have. Possibly some problem with tls handling? Which ejabberd version is that?

[kpbg]

The version is 18.12.1

I got it recently upgraded from 18.01

The issue started after the update and large Stanzas were going just fine before that (in production for months).

Not sure on the TLS, as it shouldn't be affected by the stanza size.. or am I missing something?

[prefiks]

I only mentioned tls problem as i remember that years ago there was bug that did prevent delivery of some parts of data and you got Bad Request: no data, but this definitely don't happen in recent versions.

Would you please check in your browser net panel what headers that request sends? Possibly it tries to use different transfer method that what bosh expect? What browser is that btw?

[kpbg]

It is a "Nearly up to date" Chrome (latest update is pending).

Here is the web request:

I think if Strophe is trying to use different protocol, it would be failing for the requests with 2000 length as well (they are just fine)

[prefiks]

So i have no problem with firefox or chrome for up to 64k messages on https, are you using some kind of proxy for it? From that message "Bad Request: no data" it looks like something is striping POST payload, i have no idea what could do that.

[takarogabor]

Hi, I encountered same issue today with version 18.12.1, it works witout TLS.

[kpbg]

Nope, not at all. It is a direct connection between the browser and ejabberd.

Maybe you can spot something going wrong in my config?

loglevel: 5
log_rotate_size: 10485760
log_rotate_date: ""
log_rate_limit: 1000
hosts:

• "localhost"
• "my.xxxxxxxxxxx.xxx"
• "terminal.xxxxxxxxxxx.xxxx"
  host_config:
  "terminal.xxxxxxxxxxx.xxxx":
  domain_certfile: "/etc/ejabberd/vrtcert.pem"
  "my.xxxxxxxxxxx.xxx":
  domain_certfile: "/etc/ejabberd/mysvrcert.pem"
  listen:
  -
  port: 5222
  module: ejabberd_c2s
  starttls: true
  protocol_options:
  
  
  
  • "no_sslv2"
  
  
  • "no_sslv3"
    
    ## - "no_tlsv1"
    
    max_stanza_size: 131072
    
    shaper: c2s_shaper
    
    access: c2s
    
    zlib: true
    
    -
    
    port: 5269
    
    ip: "::"
    
    module: ejabberd_s2s_in
    
    -
    
    port: 4560
    
    module: ejabberd_xmlrpc
    
    ip: "127.0.0.1"
    
    access_commands: {}
  
  

-
port: 5281
ip: "127.0.0.1"
module: ejabberd_http
request_handlers:
"/api": mod_http_api

-
port: 5280
ip: "::"
module: ejabberd_http
request_handlers:
"/websocket": ejabberd_http_ws
"/http-bind": mod_http_bind
web_admin: true
http_bind: true
captcha: false
tls: true
protocol_options:
- "no_sslv2"
- "no_sslv3"
disable_sasl_mechanisms: "digest-md5"
s2s_use_starttls: optional
certfiles: ["/etc/ejabberd/vrtcert.pem","/etc/ejabberd/mysvrcert.pem"]
s2s_protocol_options:
- "no_sslv2"
- "no_sslv3"

auth_method: external
extauth_program: "/web/terminal.xxxxxxxxxxx.xxxx/cron/ejabberd_auth.pl"
extauth_instances: 3
auth_use_cache: false
acl:
admin:
user:
- "": "localhost"

local:
user_regexp: ""
loopback:
ip:
- "127.0.0.0/8"

access:
max_user_sessions:
all: 30
max_user_offline_messages:
admin: 5000
all: 1000
local:
local: allow
c2s:
blocked: deny
all: allow
c2s_shaper:
admin: none
all: fast
s2s_shaper:
all: fast
announce:
admin: allow
configure:
admin: allow
muc_admin:
admin: allow
muc_create:
local: allow
muc:
all: allow
pubsub_createnode:
local: allow
register:
all: allow
trusted_network:
loopback: allow

language: "en"
modules:
mod_adhoc: {}
mod_admin_extra: {}
mod_announce: # recommends mod_adhoc
access: announce
mod_blocking: {} # requires mod_privacy
mod_caps: {}
mod_carboncopy: {}
mod_client_state:
queue_chat_states: false
queue_pep: false
queue_presence: false
mod_configure: {} # requires mod_adhoc
mod_disco: {}
mod_echo: {}
mod_http_bind:
use_cache: false
mod_last: {}
mod_muc:
access: muc
access_create: muc_create
access_persistent: muc_create
access_admin: muc_admin
mod_muc_admin: {}
mod_offline:
access_max_user_messages: max_user_offline_messages
mod_ping: {}
mod_privacy: {}
mod_private: {}
mod_pubsub:
access_createnode: pubsub_createnode
ignore_pep_from_offline: true
last_item_cache: false
plugins:
- "flat"
- "hometree"
- "pep" # pep requires mod_caps
mod_register:
welcome_message:
subject: "Welcome!"
body: |-
Hi.
Welcome to this XMPP server.

ip_access: trusted_network

access: register

mod_roster: {}
mod_shared_roster: {}
mod_stats: {}
mod_time: {}
mod_vcard:
search: false
mod_version: {}

allow_contrib_modules: true
api_permissions:
"API used from localhost allows all calls":
- who:
- ip: "127.0.0.1/8"
- what:
- "*"
- "!stop"
- "!start"

[prefiks]

I think this should be fixed by recent changes to our tls library, updated version should be included in ejabberd 19.02 release that should be coming soon.

[kpbg]

Thanks @prefiks

I just updated to 19.02 and everything seems to be working well (the reported issue is not present).

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.