HttpFileUploadManager issue with 4.3

Smack Smack Support
1

Hello, we are attempting an upgrade from Smack 4.2.3 to 4.3.

One of the issues we are working through involves discovering if HTTP Upload (XEP-0363) is supported by the XMPP server.

With 4.2, this has been working fine for us, against Openfire recent versions with a custom XEP-0363 implementation.
With 4.3, we are seeing this client side exception, during connection to the XMPP server.

 java.lang.IndexOutOfBoundsException: Invalid index 0, size is 0
     at java.util.ArrayList.throwIndexOutOfBoundsException(ArrayList.java:255)
     at java.util.ArrayList.get(ArrayList.java:308)
     at org.jivesoftware.smackx.xdata.FormField.getFirstValue(FormField.java:265)
     at org.jivesoftware.smackx.httpfileupload.HttpFileUploadManager.uploadServiceFrom(HttpFileUploadManager.java:160)
     at org.jivesoftware.smackx.httpfileupload.HttpFileUploadManager.discoverUploadService(HttpFileUploadManager.java:201)
     at org.jivesoftware.smackx.httpfileupload.HttpFileUploadManager$2.authenticated(HttpFileUploadManager.java:127)
     at org.jivesoftware.smack.AbstractXMPPConnection.callConnectionAuthenticatedListener(AbstractXMPPConnection.java:1261)
     at org.jivesoftware.smack.AbstractXMPPConnection.afterSuccessfulLogin(AbstractXMPPConnection.java:595)
     at org.jivesoftware.smack.tcp.XMPPTCPConnection.afterSuccessfulLogin(XMPPTCPConnection.java:380)
     at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(XMPPTCPConnection.java:445)
     at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:517)
     at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:491)
     at com.sample.login(sample.java:660)
     at com.sample.access$200(sample.java:70)
     at com.sample$6.run(sample.java:643)
     at com.sample$6.run(sample.java:686)
     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
     at java.util.concurrent.FutureTask.run(FutureTask.java:237)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
     at java.lang.Thread.run(Thread.java:818)

And subsequent calls also return false for:

HttpFileUploadManager.getInstanceFor(conn).isUploadServiceDiscovered()

Further, if we later call:

HttpFileUploadManager.getInstanceFor(conn).discoverUploadService()

Then we still see the same IndexOutOfBoundsException

Here is a snippet of the traffic received from the XMPP server showing the max-file-size is specified in the received message. But in the subsequent log from my app level logging, you can see the max-file-size is empty. Not sure how it is getting lost within the client stack, but that may be related? Or may just be a side effect of the changes to toXml() based strings/logging?

09-26 20:21:49.877 18646-18838/com.sample.app D/SMACK: RECV (0): <iq type="result" id="DGLxS-25" from="upload.sample.net" to="byoung@sample.net/ANDROID-355301074232615"><query xmlns="http://jabber.org/protocol/disco#info"><identity category="store" type="file" name="upload"/><feature var="http://jabber.org/protocol/disco#info"/><feature var="urn:xmpp:ping"/><feature var="jabber:iq:last"/><feature var="urn:xmpp:time"/><feature var="urn:xmpp:http:upload"/><x xmlns="jabber:x:data" type="result"><field var="FORM_TYPE" type="hidden"><value>urn:xmpp:http:upload</value></field><field var="max-file-size">20971520</field></x></query></iq>

09-26 20:21:49.907 18646-18854/com.sample.app D/MessageManager: processMessage: <iq xmlns='jabber:client' to='byoung@sample.net/ANDROID-355301074232615' from='upload.sample.net' id='DGLxS-25' type='result'><query xmlns='http://jabber.org/protocol/disco#info'><identity category='store' name='upload' type='file'/><feature var='http://jabber.org/protocol/disco#info'/><feature var='urn:xmpp:ping'/><feature var='jabber:iq:last'/><feature var='urn:xmpp:time'/><feature var='urn:xmpp:http:upload'/><x xmlns='jabber:x:data' type='result'><field var='FORM_TYPE' type='hidden'><value>urn:xmpp:http:upload</value></field><field var='max-file-size'></field></x></query></iq>

If we ignore the lack of successful discovery, and attempt file upload, some Smack internal checks fails so the upload does not proceed:

org.jivesoftware.smack.SmackException: No upload service specified and also none discovered.
at org.jivesoftware.smackx.httpfileupload.HttpFileUploadManager.requestSlot(HttpFileUploadManager.java:353)
at org.jivesoftware.smackx.httpfileupload.HttpFileUploadManager.requestSlot(HttpFileUploadManager.java:308)
at org.jivesoftware.smackx.httpfileupload.HttpFileUploadManager.uploadFile(HttpFileUploadManager.java:261)
at com.sample.HttpFileManager$2.run(HttpFileManager.java:229)
at com.sample$6.run(sample.java:686)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)

Please let me know if you have any thoughts or suggestions for this issue.

2

Thanks for reporting SMACK-838.

<iq xmlns=‘jabber:client’ to=‘byoung@sample.net/ANDROID-355301074232615’ from=‘upload.sample.net’ id=‘DGLxS-25’ type=‘result’>
<query xmlns=‘http://jabber.org/protocol/disco#info’><identity category=‘store’ name=‘upload’ type=‘file’/>
<feature var=‘http://jabber.org/protocol/disco#info’/><feature var=‘urn:xmpp:ping’/>
<feature var=‘jabber:iq:last’/><feature var=‘urn:xmpp:time’/>
<feature var=‘urn:xmpp:http:upload’/>
<x xmlns=‘jabber:x:data’ type=‘result’>
<field var=‘FORM_TYPE’ type=‘hidden’>
<value>urn:xmpp:http:upload</value></field><field var=‘max-file-size’></field></x></query></iq>

Note that this is an invalid XEP-0363 response. The max-file-size field has no value. Please contact the vendor and report this.

3

Thank you Flow for the response. My description probably was not clear. I will try to elaborate

If you look at the previous/first log line (which contains SMACK: RECV) you can see the max-file-size is set as expected. So I believe the value is properly coming from the other system.

The second log line (which you quoted) is the logging available in my app code, showing somehow the max-file-size was lost, perhaps by the Smack library.

I will do some digging to see if I can determine how the max-file-size value could be lost/cleared after the SMACK: RECV based logging occurs

4

<field var=“max-file-size”>20971520</field>

This is not a correct form field, cf. XEP-0363 and the data forms XEP. Please report this to the vendor of the orginating entity.

5

I see your point! thanks, I will inquire about this expected formatting:

<field var=‘max-file-size’>
<value>20971520</value>
</field>

1 Like