PUT choke on transfer-encoding chunked

[ctengel]

Some clients like requests prefer this (curl seems OK)

If you try to do content-length+transfer-encoding fastapi complains (correctly) that this is invalid and sends a 400.

If you omit content-length our code chokes.

I cannot figure out how to make requests not do this. I also have 0% clue how the old code worked since I think it would silently let it go but I don't see any provisions for handling chunks.

It would be best to just handle it I think.

Kinda related to #26 in that we are now deep in the bowels of HTTP spec.

If the old code really did work OK, then disappointing that we have to be MORE aware of what's going on in fastapi land than before. if it was silently failing (it might have since we weren't doing checksums yet...) then that's also a problem!

[ctengel]

One mystery solved. The default version of the old one was http 1.0 which clients aren't supposed to assume can do chunked.

[ctengel]

Maybe we should be less involved - no need for us to require content-length. Let's make it optional.

On client side we should still try to avoid chunked as it's never needed for OI use cases

[ctengel]

I'm actually not sure the old mystery is actually solved but it must be one of

• old client did not chunk for whatever reason
• old server magically took care of chunked for us, and also didn't care that both headers were set
• it was chunked and not handled so anything duplicated may be incorrect... which Object node concept of metadata #8 would solve in future but need to retroactively solve

regardless... we can close this issue as the current code no longer chokes, by simply not requiring content-length (technically it would still choke if you tried to do both but that is apparently OK per HTTP spec)