Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[HttpKernel] Fix that theStore would not save responses with the X-Content-Digest header present#36833

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@mpdude
Copy link
Contributor

@mpdudempdude commentedMay 16, 2020
edited
Loading

QA
Branch?3.4
Bug fix?yes
New feature?no
Deprecations?no
Tickets
LicenseMIT
Doc PR

Responses fetched from upstream sources might have aX-Content-Digest header, for example if the Symfony Cache is used upstream. This currently prevents theStore from saving such responses. In general, the value of this header should not be trusted.

As I consider this header an implementation detail of theStore, the fix tries to be local to that class; we should not rely on theHttpCache or other classes to remove untrustworthy headers for us.

This fixes the issue that when using theHttpCache in combination with the Symfony HttpClient, responses that have also been cached upstream in an instance ofHttpCache are not cached locally. It adds the overhead of re-computing the content digest every time theHttpCache successfully re-validated a response.

@mpdudempdudeforce-pushed thecache-upstream-content-digest-34 branch 2 times, most recently fromaa18ef9 to6726bacCompareMay 17, 2020 09:44
@nicolas-grekasnicolas-grekas added this to the3.4 milestoneMay 18, 2020
@nicolas-grekasnicolas-grekasforce-pushed thecache-upstream-content-digest-34 branch from60512dc tod8964fbCompareMay 19, 2020 16:37
@nicolas-grekas
Copy link
Member

Thank you@mpdude.

@nicolas-grekasnicolas-grekas merged commitaf0df4c intosymfony:3.4May 19, 2020
@mpdudempdude deleted the cache-upstream-content-digest-34 branchMay 19, 2020 16:48
This was referencedMay 26, 2020
mpdude added a commit to mpdude/symfony that referenced this pull requestJun 10, 2020
fabpot added a commit that referenced this pull requestJun 11, 2020
…sponse body correctly (mpdude)This PR was squashed before being merged into the 3.4 branch.Discussion----------[HttpKernel] Fix regression where Store does not return response body correctly| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | yes| New feature?  | no| Deprecations? | no| Tickets       |Fix#37174| License       | MIT| Doc PR        |Since#36833, the `Store` no longer uses or trusts the `X-Content-Digest` header present on a response, since that may come (in the case of using `CachingHttpClient`) from upstream HTTP sources. Instead, the `X-Content-Digest` is re-computed every time a response is written by the `Store`.Additionally, the `Store` is implemented in a way that when restoring responses, it does _not_ actually load the response body, but just keeps the file path to the content on disk in another internal header called `X-Body-File`. It is up to others (`HttpCache`, for example) to actually load the content from there. For reasons I could not determine, the file path is also set as the response body.When the `HttpCache` performs revalidations, it may happen that it wants the `Store` to persist a previously restored response. In that case, the `Store` fails to honor its own `X-Body-File` header. Instead, it would compute (since#36833) the `X-Content-Digest`, which now is a hash of the cache file path.So, we end up with a response that still carries `X-Body-File` for the original, correct response. Since the `HttpCache` honors this value, we don't immediately notice that. But inside the `Store`, the request is now associated with the _new_ (bogus) content entry.It takes another round of looking up the content in the `Store` to now get a response where the `X-Body-File` _also_ points to the wrong content entry.Although I feel a bit uncomfortable with trusting headers that seemingly need to be evaluated in different classes and may come from elsewhere, my suggestion is to skip the write inside `Store` if `X-Body-File` and `X-Content-Digest` are both present and consistent with each other.Additionally, a `file_exists` check could be added to provide additional assertions, at the cost of accessing the filesystem.Commits-------176e769 [HttpKernel] Fix regression where Store does not return response body correctly
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas left review comments

@fabpotfabpotfabpot approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

4 participants

@mpdude@nicolas-grekas@fabpot@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp