Demystifying iControl REST Part 5: Transferring Files
Updated Aug 04, 2023
Version 5.0Was this article helpful?
We are programmatically uploading files to our F5 devices.
The following command WORKS correctly, but does NOT follow RFC 7233 4.2:
curl -i -sk -u admin:admin -X POST -H "Expect:" \
-H "Content-Type: application/octet-stream" \
-H "Content-Range: 0-1333/1334" --data-binary "@domain.crt" \
"https://192.168.1.1/mgmt/shared/file-transfer/uploads/domain.crt"
The following command does NOT work correctly, but DOES follow RFC 7233 4.2: curl -i -sk -u admin:admin -X POST -H "Expect:" \ -H "Content-Type: application/octet-stream" \ -H "Content-Range: bytes 0-1333/1334" --data-binary "@domain.crt" \ ";
The main difference is the use of the HTTP Header
Content-Range
including the word "bytes" with the values. RFC 7233 4.2 indicates that this should be (example from RFC) Content-Range: bytes 42-1233/1234
However whenever we include the word "bytes" the F5 responds with a HTTP 400, error follows:
HTTP/1.1 400 Bad Request
Date: 08 Dec 2017 23:51:54 UTC
Server: com.f5.rest.common.RestRequestSender
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=16070400; includeSubDomains
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
Expires: -1
Content-Length: 135
Content-Type: application/json
REMOTEROLE: 0
Local-Ip-From-Httpd: 127.0.0.1
Session-Invalid: true
X-Forwarded-Server: localhost.localdomain
X-Forwarded-Proto: http
REMOTECONSOLE: /sbin/nologin
X-Forwarded-Host: 192.168.1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' http://127.4.1.1 http://127.4.2.1
Connection: close
{"code":400,"message":"Missing 'Content-Range' header","referer":"192.168.1.2","restOperationId":66478298,"kind":":resterrorresponse"}%
However whenever we do NOT include the word "bytes" the F5 responds with a HTTP 200 and the file is created on the F5 in the
/var/config/rest/downloads
directory, but again fails to follow follow RFC 7233 4.2 which our application code is enforcing.