Current range requests are unreliable. This stems from a change in 3.1 where range transforms were moved from being a special case to being generic transforms. This had the side effect of disabling special case code that adjusted the content length correctly.

Having looked at the code I think it would be difficult to re-implement the special case logic successfully. The root of the problem is distinguishing the built in range transforms from other transforms. Rather than do that specifically, it seems better to provide a general mechanism which can be used by the internal range transforms and are also available to other plugins.

The goal is to enable transform plugins to more directly indicate the content length resulting from the operation of the plugin.

This would be done by providing another callback for transform plugins,

TS_HTTP_TRANSFORM_CONTENT_LENGTH_HOOK.

The hook would be called in source to output sequence. The first transform would be called first, then each subsequent transform, until the last transform was called. For each call the transform would be passed the source content length and the content length provided by the just previous transform. It would then return a content length indicating how long the content will be after its transformation.

The returned content length can be either an explicit length (in bytes) or the special value INDETERMINATE. This indicates the transform does not know (or cannot provide) the expected output length. Any transformation plugin that does not register a callback for the hook will be treated as if it returned INDETERMINATE from the hook (which should preserve current behavior). The internal range transforms will use this to return a value computed from the range information.

If the resolution is INDETERMINATE then Traffic Server will remove the Content-Length field and use chunked encoding or disable keep-alive to signal the end of document as is done now.

The main goals of this change are

  1. Preserve existing behavior without any change to existing transform plugins.
  2. Handle the special case of a transform setup that consists of only the range transform.
  3. Not break the general case of multiple transforms.

As secondary goals, it would be handy for other transform plugins that are singletons to be able to reliably report the expected content length as this is the usual case (stacked transforms are relatively rare in actual deployment).

  • No labels