Content Length Required

[vsoch]

I wanted to open up some discussion about the Content-Length header. Currently the spec does not say that all responses are required to have it, and this possibly makes sense because we could look it up, say, in the manifest, but since Content-Length is sort of bread and butter when it comes to communicating about requests/responses, is there any reason to not have it? Many libraries can find this field useful, so we are proposing to have it added to all registry responses that make sense for a future release:

https://supercontainers.github.io/containers-wg/ideas/content-length_D2/

cc @reidpr

[reidpr]

It's worth pointing out that most registries already do this. I've only encountered one that didn't, though I forget which one.

[kzys]

I don't want to make that mandatory. Content-Length is optional in HTTP itself and will block the use of Transfer-Encoding;

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

The distribution spec shouldn't block certain HTTP features.

[vsoch]

But we are already requiring it for a lot of interactions… What am I missing?

[reidpr]

I guess I'd prefer an argument based on what we actually want to do, rather than a bare reference to the standards.

For example, a few minutes on Google suggests that Transfer-Encoding is good for large responses where the length isn't known beforehand. That doesn't apply to manifests. We could simply disallow Transfer-Encoding for certain responses, which eliminates the conflict.