[joelkeener]

Summary

Fixes certificate and file upload failures caused by Content-Range header calculation mismatch. When uploading files, the module was calculating Content-Range using total file size instead of actual bytes in the chunk, causing BIG-IP REST API to reject uploads with "Chunk byte count X different from received buffer length Y" error.

Changes

Module Updates:

• icontrol.py — Removed conditional logic that used total file size for last chunk; now always calculates end = start + current_bytes to ensure Content-Range matches actual bytes being transmitted

Tests:

• test_icontrol_upload.py — New comprehensive test suite with 3 test cases covering:
  • Single small chunk Content-Range accuracy
  • Multi-chunk file upload handling
  • RFC 7233 compliance

Affected Modules

This fix resolves upload issues in all modules using upload_file():

• bigip_ssl_certificate
• bigip_ssl_key
• bigip_ssl_key_cert
• bigip_data_group
• bigip_iapp_template
• bigip_asm_policy_import
• bigip_apm_policy_import
• bigip_imish_config
• bigip_ucs

Testing

Unit tests added verifying Content-Range header consistency with actual transmitted bytes across single-chunk and multi-chunk scenarios, ensuring RFC 7233 compliance.

Checklist

• Unit tests added and syntax validated
• Code follows project conventions
• No security concerns identified

[crosbygw]

The core fix is correct (icontrol.py:538-541). The bug was that the old code set end = size for the final chunk of a multi-chunk upload instead of end = start + current_bytes. This overstated the Content-Range byte count whenever start > 0 (i.e., any file larger than one chunk), causing the BIG-IP error mentioned in the test docstring. The fix was verified via byte-level simulation across various file sizes.

Two non-blocking issues with the test file (test_icontrol_upload.py):

1. Location: Placed in tests/unit/modules/, but should follow the existing convention (tests/unit/module_utils/network/f5/) since icontrol.py lives in plugins/module_utils/.
2. Coverage gap: The test named test_large_file_multi_chunk_content_range_consistency actually only exercises a single-chunk upload (1000 bytes vs ~7MB chunk size) — the test's own comment admits this. None of the three tests actually cover the multi-chunk scenario (start > 0) that the fix specifically targets.

No behavior change for single-chunk uploads — fix only affects output for multi-chunk uploads on the final short chunk, which is the intended target.

Note: A pre-existing retry bug (not resetting start to 0) was noticed but is out of scope since it's untouched by this diff.

Recommendation: Move the test file to the conventional location and add a test that actually forces multiple chunks (e.g., by monkeypatching chunk_size) to validate the specific scenario the fix addresses.