Mobile App Icon Upload via API

luke_reagor
Contributor II

I am having trouble uploading an icon to an app. The icon file exists and I have rights to it. Other API calls work normally to the app... I can even update the version and description. I have tried with jpg and png. The original jpg was downloaded directly from Apple based on the url in the App Store json for the app. I've also tried different locations for the icon file. Everything I do gives me this error:
<html>
<head> <title>Status page</title>
</head>
<body style="font-family: sans-serif;">
<p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">Conflict</p>
<p>Unable to complete file upload. No file found for the upload.</p>
<p>You can get technical details <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10">here</a>.<br>
Please continue your visit at our <a href="/">home page</a>.
</p>
</body>
</html>

Here's the command I'm using:

curl -k -u ${JSSUSER}:${JSSPASS} -X POST https://jamf.domain.com:8443/JSSResource/fileuploads/mobiledeviceapplicationsicon/id/${APPID} -F name=@"/tmp/icon.png"
3 REPLIES 3

luke_reagor
Contributor II

Curl's verbose info shows the Content-Length as 19752 which is correct. That tells me that the file was found and read.

  • Trying x.x.x.x...
  • TCP_NODELAY set
  • Connected to jamf.domain.com (x.x.x.x) port 8443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server did not agree to a protocol
  • Server certificate:
  • SSL certificate verify ok.
  • Server auth using Basic with user 'JSSUSER' > POST /JSSResource/fileuploads/mobiledeviceapplicationsicon/id/169 HTTP/1.1 > Host: jamf.domain.com:8443 > Authorization: Basic SlNTQVBJOkoyMkFQMQ== > User-Agent: curl/7.58.0 > Accept: / > Content-Length: 19752 > Content-Type: multipart/form-data; boundary=------------------------bc277b3030ee26c1 > Expect: 100-continue > < HTTP/1.1 100 < HTTP/1.1 409 < X-FRAME-OPTIONS: DENY < Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0 < Date: Thu, 26 Mar 2020 20:04:45 GMT < Accept-Ranges: bytes < Server: Restlet-Framework/2.3.12 < Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept < X-XSS-Protection: 1; mode=block < Strict-Transport-Security: max-age=31536000 ; includeSubDomains < Content-Type: text/html;charset=UTF-8 < Content-Length: 443 < Set-Cookie: SRVSTICKY=jamf; path=/
  • HTTP error before end of send, stop sending < <html> <head> <title>Status page</title> </head> <body style="font-family: sans-serif;"> <p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">Conflict</p> <p>Unable to complete file upload. No file found for the upload.</p> <p>You can get technical details <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10">here</a>.<br> Please continue your visit at our <a href="/">home page</a>. </p> </body> </html>
  • Closing connection 0
  • TLSv1.2 (OUT), TLS alert, Client hello (1):

luke_reagor
Contributor II

Found that the issue only occurs when going through our load balancer. Now to figure out what HAProxy is doing to the upload.

luke_reagor
Contributor II

I found the issue. The HAProxy setting 'option http-server-close' was closing off the multipart form-data before it finishes uploading. I changed the settings to use 'option http-keep-alive' and 'timeout http-keep-alive 3000' to give the sessions enough time to upload before closing. So far it's working.