Http upload file send is defective when server (jabberd) is configured with max_size: infinity

[emildekeyser]

Sending files either doesnt work (after selecting file, you get an error) or uses jingle instead of http upload when both sides are online. This occurs with ejabberd when the max_size parameter from mod_http_upload is set to 'infinity'. Setting it to a arbitray number fixes the issue.

[Yuubi-san]

The immediate bug seems to be in Dino.Plugins.HttpFiles.HttpFileSender.can_send() at

dino/plugins/http-files/src/file_sender.vala

Line 55 in 47a0669

return file_transfer.size < max_file_sizes[conversation.account];

which doesn't check max_file_sizes[conversation.account] for negativity. Max file size of -1, in turn, comes from Xmpp.Xep.HttpFileUpload.Module.extract_max_file_size() at

dino/xmpp-vala/src/module/xep/0363_http_file_upload.vala

Line 184 in 47a0669

return -1;

when the size limit attribute is absent in the XML (which is allowed by the XEP).

The Right Way (TM) to fix this, IMO, is to not signal non-numeric information in-band with numeric information, e.g., return long? instead of long from extract_max_file_size.

[mar-v-in]

Nullable value types are still rather experimental in Vala (there is a compiler flag --enable-experimental-non-null to add proper nullable checking, but that's still considered experimental). If extract_max_file_size() returned a long? of value null, the comparison for the transfer size would be "valid", but segfault if no further checks are added.

We generally prefer "misbehavior" over segfaults, that's why we try to not use nullable value types (like long?, int?, bool?; nullable reference types do not segfault). That's why I'd prefer to just make extract_max_file_size return long.MAX for unlimited file size.