assets:install should keep ctime/mtime when in copy mode

[zerkms]

Description

Creation/last modification time of the web assets is used by web servers in the Last-Modified header.

Hence if you have multiple instances of the application which had their assets:install run at different times - depending on what instance you hit - you may receive different values which would confuse the web server (as Last-Modified must match the If-Modified-Since exactly) and it would return http 200 and entire asset, instead of http 304.

Example

none

[smnandre]

@zerkms: How do you retrieve the "ctime/mtime" values? As far as I know, files are timestamped when you pull them from Git, and they don't retain their original timestamps. Wouldn't this result in differences depending on the build time?

Regarding caching, an 'immutable' cache header + long duration represents imho a better approach for caching static assets than LastModified (only), as they are versioned and never change afterwards. And i'm not sure i'd want a deployment script to mess with files metadata, this could have other side effects.

Another solution could be to use hash-based ETags, removing the need for timestamps ?

Some links about immutable/best practices :

• https://blog.developer.adobe.com/an-http-caching-strategy-for-static-assets-configuring-the-server-1192452ce06a
• https://simonhearne.com/2022/caching-header-best-practices/
• https://web.dev/articles/http-cache#summary

[zerkms]

How do you retrieve the "ctime/mtime" values?

whatever it is currently in the filesystem.

Wouldn't this result in differences depending on the build time?

It's fine, at least it will be the same everywhere.

And i'm not sure i'd want a deployment script to mess with files metadata, this could have other side effects.

This is controversial: deployment scripts deal with files - be it files contents, names, or metadata - I don't see any difference.

Some links about immutable/best practices

I know how caching in http works and how to workaround the problem. My suggestion is to not create problems in the very first place so that you didn't need to bring even more configuration to solve it.

Nonetheless, I suggest to NOT discuss "the best practices" of how it should be done otherwise. My suggestion is - would the symfony team consider it, or not?

[smnandre]

I apologize if my message caused any offense; that was never my intention. I have recently dedicated some time to researching this topic and shared those bookmarks with the sole hope that they might be of interest to anyone reading this issue.

[nicolas-grekas]

IMHO, this concern doesn't belong to this command. We don't have mtime to keep track of.
Instead, I'd suggest syncing mtimes with the last update of each files in the git history.

This does it (using concurrency to be a bit faster than a simple loop):

git ls-tree -r --name-only HEAD | xargs -I {} -P $(nproc) bash -c '
filename="$1"
commitDate=$(git log -1 --format="%ai" -- "$filename")
if [ -n "$commitDate" ]; then
    touch -d "$commitDate" "$filename"
fi
' _ {}

[zerkms]

We don't have mtime to keep track of.

How do you know that? It's not symfony's domain of responsibility to know how and where the source code retrieved from :-)

Anyway, assets:install keeps the files contents, their names. Any reason to not keep metadata? Possibly through another option?

[nicolas-grekas]

Why would we when I just gave a nice solution?

[zerkms]

a nice solution

it's a workaround, not a solution: you could have copied the assets with a bash scripts too, but instead there is command for that.

So, why would the command retain names, and content, but drop metadata? Any particular reason to NOT keep metadata?

[xabbuh]

The root cause is that in Filesystem::mirror() we use stream_copy_to_stream() under the hood. I opened #54362 to keep the modification time in the same way that we preserve file permissions.

[nicolas-grekas]

Ah, thanks for digging this @xabbuh!