Skip to content

Dont check "Cache-Control: no-transform" in encode directive #7561

Open
elee1766 wants to merge 4 commits intocaddyserver:masterfrom
elee1766:dont-respect-cache-control-no-transform
Open

Dont check "Cache-Control: no-transform" in encode directive #7561
elee1766 wants to merge 4 commits intocaddyserver:masterfrom
elee1766:dont-respect-cache-control-no-transform

Conversation

@elee1766
Copy link
Contributor

@elee1766 elee1766 commented Mar 10, 2026

Currently, the encode directive will not compress if the no-transform value is set in the cache-control header.

this was changed in #5257

in which it was floated in this souin issue that darkweak/souin#289 that perhaps encode should respect the no-transform directive.

cited was these specifications:

rfc-editor.org/rfc/rfc7234#section-5.2.1.6
rfc-editor.org/rfc/rfc7234#section-5.2.2.4

which state:

The "no-transform" request directive indicates that an intermediary
   (whether or not it implements a cache) MUST NOT transform the
   payload...
The "no-transform" response directive indicates that an intermediary
   (regardless of whether it implements a cache) MUST NOT transform the
   payload... 

Since caddy is being used as an intermediary in the case of souin, i believe this is why the behavior was added to the encode directive.

However, I believe that this is incorrect to do. this is because the specification clearly states that it is an intermediary that must not transform the payload, and the encode directive, along with caddy itself, is not always used as an intermediary. one example could be serving files from disk.

if one is to run caddy as an intermediary, it would be correct then the user i believe to do something like

@no-no-transform not header Cache-Control no-transform 
encode @no-no-transform

instead of using the encode middleware bare. this behavior shot me in the foot trying to use caddy behind a cdn. both trafik and nginx do not seem to perform this check for no-transform.

not sure if @darkweak you have any strong opinions about this, since you added this originally for your consumer. maybe it would make sense for the matcher to be added to souin examples?

Assistance Disclosure

n/a

@mholt
Copy link
Member

mholt commented Mar 10, 2026

Thanks for pointing out the wording of the spec, I wasn't aware of that.

Yeah I agree we should make sure both origin and intermediary roles are served well.

In the case of using souin, then it is an intermediary, and perhaps souin should be responsible for handling that somehow, or documenting to the user how to configure encode accordingly for that.

Also curious to hear Sylvain's thoughts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants