[HttpKernel] Fixes AppCache + ESI + Stopwatch problem #7180
Conversation
| @@ -410,7 +417,11 @@ private function postDispatch($eventName, Event $event) | |||
| break; | |||
| case KernelEvents::TERMINATE: | |||
| $token = $event->getResponse()->headers->get('X-Debug-Token'); | |||
| $this->stopwatch->stopSection($token); | |||
| // In the special case described in th `preDispatch` method above, the `$token` section | |||
There was a problem hiding this comment.
@lsmith77 thanks, do you find this comment understable?
There was a problem hiding this comment.
well as understandable as something as complex as this can get i guess :)
|
@vicb never agrees :) I don't have time to check this deeply now but I would like to see a UT. Could your use case be expressed as "on nested terminate events" ? |
|
@vicb If I had an idea on how to write a conclusive test for that, I swear, it would be provided in this PR. |
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #7180). Commits ------- 6a33bc2 [HttpKernel] Fixes AppCache + ESI + Stopwatch problem Discussion ---------- [HttpKernel] Fixes AppCache + ESI + Stopwatch problem There is a very special case when using builtin AppCache class as kernel wrapper, in the case of an ESI request leading to a `stale` response [B] inside a `fresh` cached response [A]. In this case, `$token` contains the [B] debug token, but the open `stopwatch` section ID is equal to the [A] debug token. Trying to reopen section with the [B] token throws an exception which must be caught. | Q | A | ------------- | --- | Bug fix? | yes | Bug mask? | no, does @vicb agree? | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #6227, #6230 I tried to find a better solution than just wrapping thrown exceptions with `try/catch`, but IMHO the #6230 solution from @lsmith77 was in fine the best one. I just added some comments in the code to avoid the WTF reactions while reading it. --------------------------------------------------------------------------- by vicb at 2013-02-25T16:51:51Z @vicb never agrees :) I don't have time to check this deeply now but I would like to see a UT. Could your use case be expressed as "on nested terminate events" ? --------------------------------------------------------------------------- by jfsimon at 2013-02-25T16:58:49Z @vicb If I had an idea on how to write a conclusive test for that, I swear, it would be provided in this PR.
|
Jef, my remark (nested or more accurately successive terminate events) was a hint for a test & may be a better fix. "Jean-François Simon" [email protected] wrote:
|
|
Ah okay Victor, I try something, tell me if it matches your idea: This case is really specific and difficult to explain with simplicity. |
|
If you want to use appcache a ft is probably best. Otherwise you should be able to simulate a simpler tc. The main thing to keep in mind is not the stopwatch issue specifically imo but terminate in general and the diff in behavior with a "real" reverse proxy. "Jean-François Simon" [email protected] wrote:
|
There is a very special case when using builtin AppCache class as kernel wrapper, in the case of an ESI request leading to a
staleresponse [B] inside afreshcached response [A]. In this case,$tokencontains the [B] debug token, but the openstopwatchsection ID is equal to the [A] debug token. Trying to reopen section with the [B] token throws an exception which must be caught.I tried to find a better solution than just wrapping thrown exceptions with
try/catch, but IMHO the #6230 solution from @lsmith77 was in fine the best one. I just added some comments in the code to avoid the WTF reactions while reading it.