Content-Length -vs- Transfer-Encoding: chunked

[Mark Aldred]

Is there any way that I can get a "Content-Length" header rather than the "Transfer-Encoding: chunked" in response to GET requests?  Handling the Content-Length header is trivial, while the chunked response is rather unpleasant from within my application.

[Travis McLane]

Currently there is no way to have the API send the response in that manner.
I will file an enhancement request to have this added to the API.

Do you mean in all GET responses (including raw data)?
Or just in the API XML responses?

[Mark Aldred]

Hi Travis,

I'm not sure that an enhancement request is appropriate at this time.  Currently my application is working with using the Transfer-Encoding header but the Content-Length header is a "nice to have" feature.  I suppose that when V3 is available that the Content-Length header will be used because that is what S3 uses.  Perhaps I'm misunderstanding what will be in V3.   Anyway, I'm just looking for a way to know the size of the data that being transfered for a GET request before my application starts copying the data from cURL so that I can allocate a buffer of the proper size.

[Travis McLane]

If you were to retrieve the application/vnd.csp.file-info+xml data for the file you were going to GET before executing the request the total size of the file would be known.

The V3 you are speaking of is the upcoming platform version not the API version.
The V2 API will continue to be the same for all intents and purposes.
Additional capabilities will be exposed but the basic shape of things will remain the same.

[Mark Aldred]

Yes, of course I can file-info.  How did I overlook that?!  Thanks.
I guess I totally misunderstood what V3 is all about. I thought it was going to include a S3 compatible REST API.