Added information in regards to DFS and static files

[mateuszbieniek]

Question	Answer
Type	Improvement
Target version	1.0
BC breaks	no
Doc needed	yes

If the project is set to use DFS to serve static files, the Response's Vary header will always be set to Cookie, Authorization due to the missing X-User-Hash header inside Request coming from Varnish.

[lserwatka]

@ezsystems/documentation-team for review.

[vidarl]

The proposal to remove the given if will likely fix the issue yes ( not tested on my part though).
However, we go for this change, the fix needs to be added to Fastly's vcl too..

It must also be documented better ( in the docs for setting of dfs cluster )

Also, in regards to Fastly, we (or actually Platform.sh) don't want clients to run custom vcls, that means that we need to provide two vcls (for instance fastly/ez_main.vcl and fastly/ez_main_dfs.vcl)

However, it would also be possible to autodetect from the vcl if backend is runnning in dfs or not:

• Create a controller that returns whatever the dfs handler is enabled or not
• in vcl, call that controller in the same way already do with invalidate token and check with that response if we should do the return (hash) or not

As a last thought, would it be so bad to simply remove that return (hash) to everyone? yes, there will then always be a restart for fetching X-User-Context-Hash, also when fetching assets. But it would anyway be cached and overhead should be minimal.

[mateuszbieniek]

Hi @vidarl - Please take a second look - I've probably updated the text when you were writing your review.
But I agree that this might not be the best solution - probably we should introduce a second file for the dfs setup and take advantage of the fact, that User context should be applied only for:

/var/([^/]+/)?storage/images(-versioned)?/

👍

[vidarl]

I didn't see that last commit while doing the review, correct.
And you are right, it is quite different if a file is located in assets/ or var/
But I think I would rater say skip User Context for any file in assets/, and get User Context for anything else.

For instance, a .pdf file would never be located in (....)/storage/images(...), but we still would like to get User Context for it

[alongosz]

@vidarl @mateuszbieniek this one looks like a "low hanging fruit" mergabe without QA as it applies to code comment only. What is the status here?

I see that this applies to eZ Platform 2.5, which is now past EOM, so it would require a rebase.