Bugzilla

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts, and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding

We could consider providing a further mechanism to affect the Content-Encoding of artifacts, in a future release of generic-worker. Although I'm not sure at the moment what the best way to do that might be.

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressing artifacts, but have them served in a way that respects the `Content-Encoding` request header.

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts, and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`.
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding.

We could consider providing a further mechanism to affect the Content-Encoding of artifacts, in a future release of generic-worker. Although I'm not sure at the moment what the best way to do that might be.

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressed artifacts, but have them served in a way that respects the `Accept-Encoding` request header.

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts, and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`.
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding.

We could consider providing a further mechanism to affect the Content-Encoding of artifacts, in a future release of generic-worker. Although I'm not sure at the moment what the best way to do that might be.

Rob, are either of these options worthwhile?

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressed artifacts, but have them served in a way that respects the `Accept-Encoding` request header.

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts (rather than a single directory artifact), and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`.
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding.

We could consider providing a further mechanism to affect the Content-Encoding of artifacts, in a future release of generic-worker. Although I'm not sure at the moment what the best way to do that might be.

Rob, are either of these options worthwhile?

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressed artifacts, but have them served in a way that respects the `Accept-Encoding` request header.

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts (rather than a single directory artifact), and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`.
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding.

Both options have major downsides. Either you now need to maintain a list of artifacts that are published, rather than just including all files inside a directory, or you have to sacrifice the ability to compress all of the artifacts, rather than just the one you want to not compress.

We could consider providing a further mechanism to affect the Content-Encoding of artifacts, in a future release of generic-worker. Although I'm not sure at the moment what the best way to do that might be.

Rob, are either of these options worthwhile?

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressed artifacts, but have them served in a way that respects the `Accept-Encoding` request header.

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts (rather than a single directory artifact), and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`.
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding.

Both options have major downsides. Either you now need to maintain a list of artifacts that are published, rather than just including all files inside a directory, or you have to sacrifice the ability to compress any of the artifacts, rather than just the one you want to not compress.

We could consider providing a further mechanism to affect the Content-Encoding of artifacts, in a future release of generic-worker. Although I'm not sure at the moment what the best way to do that might be.

Rob, are either of these options worthwhile?

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressed artifacts, but have them served in a way that respects the `Accept-Encoding` request header.

Looking at the [task definition](https://queue.taskcluster.net/v1/task/KrDpB_bYQSGZortUtl-f4A), I see a directory artifact is used rather than a list of file artifacts, and so with the current feature, you would only be able to specify a single Content-Encoding header for all published artifacts of the directory.

So I think the two options available with generic-worker 16.2.0 are:

1) Change task definition to list all published artifacts as file artifacts (rather than a single directory artifact), and specify `"contentEncoding": "identity"` for artifact `public/build/install/sea/target.installer.exe`.
2) In the existing directory artifact, specify `"contentEncoding": "identity"` so that all artifacts `public/build/*` will have identity encoding.

Both options have major downsides. Either you now need to maintain a list of artifacts that are published, rather than just including all files inside a directory, or you have to sacrifice the ability to compress any of the artifacts, rather than just the one you want to not compress.

Rob, are either of these options worthwhile?

We could consider modifying generic-worker to allow a file artifact to take precedence over a directory artifact, such that you could overwrite the contentEncoding just for a single file within a directory artifact, but that doesn't exist as a feature yet, and we'd need to think about whether that is really desirable.

Ultimately we are probably solving this in the wrong place - the content platform should respect the `Accept-Encoding` request header, and unfortunately anything we do in the worker only avoids the issue rather than solves it.

I wonder if we should revisit this issue to see if there is a way we can achieve the storage gains of compressed artifacts, but have them served in a way that respects the `Accept-Encoding` request header.