Comment 5 for bug 1982874

Eventually I solved this puzzle.

tcpdump showed that there are two transfer-encoding headers sent:

12:14:55.894667 IP 192.168.24.1.44722 > 192.168.24.1.8080: Flags [P.], seq 0:1579, ack 1, win 512, options [nop,nop,TS val 4247042889 ecr 4247042889], length 1579: HTTP: PUT /v1/AUTH_4871e691209040999d87900ffa281fd0/tempest-TestContainer-1848004873/tempest-TestObject-1748985446 HTTP/1.1
E.._T.@.@.................UQ...............
.$.I.$.IPUT /v1/AUTH_4871e691209040999d87900ffa281fd0/tempest-TestContainer-1848004873/tempest-TestObject-1748985446 HTTP/1.1
host: 192.168.24.3:8080
accept-encoding: identity
user-agent: python-urllib3/1.26.5
transfer-encoding: chunked
x-auth-token: gAAAAABjEKI_aAD_...
transfer-encoding: chunked
x-forwarded-proto: http
x-forwarded-port: 8080
x-forwarded-for: 192.168.24.3

While this is okay-ish according to RFC2616 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2), Swift will deliberately reject this if multiple headers are sent (https://github.com/openstack/swift/commit/5174b7f85dea42b6e0a50ee0a222637be0cea240).

Actually urllib3 adds the transfer-encoding header for chunked transfers, even if Tempest already set the header before (https://github.com/openstack/tempest/blob/master/tempest/api/object_storage/test_object_services.py#L189-L195).

However, this has been changed in urllib3 1.26.6 - while the installed version is 1.26.5 (https://github.com/urllib3/urllib3/blob/main/CHANGES.rst#1266-2021-06-25).

I updated urllib3 to 1.26.6 and the test is passing correctly then, with tcpdump showing only a single transfer-encoding header sent by Tempest/urllib3.