chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlo Sciolla <>
Subject Re: Chunked transfer encoding
Date Tue, 07 May 2013 13:12:37 GMT
Hi Florian,

our use cases currently revolve around caching. As an example, we found out
quite some browsers fail to cache HTTP responses when encoded in chunks.
The same applies to some intermediate cache middleware between our CMIS
repository and the browser.

It would be indeed great if we had some hooks in the serialization process
to influence the HTTP details of the CMIS responses before they're sent
back to the client, at least setting headers such as Content-Length,
Cache-Control, ETag, etc.


2013/5/7 Florian Müller <>

> Hi Carlo,
> We could add something here, but that is usually not necessary. HTTP 1.1
> clients should be able to deal with chunks. And even if we do it, the app
> server could decide to remove the Content-Length header again if it, for
> example, compresses the outgoing stream.
> Could you describe your use case? Are you looking for general switch or a
> hint per document?
> Florian
>  Dear chemists,
>> we are trying to have our OpenCMIS based server produce HTTP response with
>> a Content-Length header and without the Transfer-encoding: chunked one. It
>> appears to me that the default behavior stems from OpenCMIS never setting
>> the Content-length, letting the app server use the default chunked
>> encoding
>> in such cases. Is there any way we can at least hook to properly set the
>> Content-length at least for the getContentStream REST operation?
>> Thanks,
>> c.

Carlo Sciolla

Linux User #372086
My personal blog:
Follow me on twitter:
<>Fork me on Github:
 <>My LinkedIn profile:

Product Lead at Backbase - Next Generation Portal Software for Financials &
Large Enterprises (

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message