@jens thanks got you…
First issue comments says "By setting the size of the underlying data on InputStreamBody at construction time, and returning the value in getContentLength(), this allows apache HTTPClient to send attachments to the server unchunked."
Is this the current behavior?
Android CBL 1.2 Attachments PUT request goes has chunked to SyncGateWay?
If so how and where is octets split done 984/4280/4096 bytes in java or android?
I think what you’re asking about is an implementation detail of the HTTP library being used in Android. It shouldn’t be anything a CBL client app needs to deal with. Could you explain what specifically you need to know and why? Are you experiencing a bug, or performance problems, or something?
(Note that depending on details of the HTTP library is a bad idea, because we’re very likely to switch to a different library in our next release.)
That doesn’t make any sense. There’s nothing in the HTTP/1.1 spec about a limit on the number of chunks in a chunk-coded body. This sounds more like some implementation limit in the proxy’s parser, and they’re making an excuse that it’s invalid input.
I don’t think any of us on the team know the details of how the HTTP library chunk-encodes bodies. You’d probably need to dig into the implementation of that library. (Sorry I can’t be more detailed, but I don’t work on our Java implementation.)
It is possible that we could improve the way we send this HTTP body such that it wouldn’t need to be chunk-encoded at all; generally if you can specify the size of the data up front, chunk encoding isn’t necessary. Again, I don’t know the details here. @hideki is the expert on the Java implementation.
But in the short term, I think your best option is to work around your proxy’s problem. Can you turn off the setting/policy that triggers this error?