If enablePublishingCompression is set on the client, posts
will be submitted with compression. The entity is buffered
and compressed before sending, which allows the content length
to be submitted, at the cost of initial buffering. Library users
will have to turn on compression support to avoid changing the
default behaviour of previous versions. Placing compression behind
a CompressionSupport interface allows alternative compression
providers in the future. The default implementation is gzip.
String posting is handled slightly differently to object posting; in
particular strings arenot minified before compression (doing this would
incur the overhead of marshalling the string to an object to minify it).
For gzip, an alternative to look at in the future is to stream and gzip at
the same time. This would avoid the initial buffer, and would require
sending Transfer-Encoding: chunked in place of the Content-Length,
since the length wouldn't be know in advance.
conorclifford
commented
2 years ago
If
enablePublishingCompressionis set on the client, posts will be submitted with compression. The entity is buffered and compressed before sending, which allows the content length to be submitted, at the cost of initial buffering. Library users will have to turn on compression support to avoid changing the default behaviour of previous versions. Placing compression behind aCompressionSupportinterface allows alternative compression providers in the future. The default implementation is gzip.String posting is handled slightly differently to object posting; in particular strings arenot minified before compression (doing this would incur the overhead of marshalling the string to an object to minify it).
For gzip, an alternative to look at in the future is to stream and gzip at the same time. This would avoid the initial buffer, and would require sending
Transfer-Encoding: chunkedin place of theContent-Length, since the length wouldn't be know in advance.