powered by Jive Software

HttpFileUploadManager issue with 4.3

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.

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.

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

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

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

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

1 Like