I don't think that FragmentListener or AccessDeniedHttpException are responsible. Can you provide a full stack trace ? or a fork of SE with this beahvior ?

@fmeynard I think there is a bug with the handling of exceptions when they are thrown in the listeners in some cases

exactly. throwing AccessDeniedHttpException is correct, but this should
lead to a 403 response.

I can't reproduce: I managed to throw an AccessDeniedHttpException in FragmentListener by faking a call to a fragment with an unsafe method, I got a 403 status as required.

I don't know if it is linked...
When calling createAccessDeniedException() in FrameworkBundle Controller a Symfony\Component\Security\Core\Exception\AccessDeniedException is thrown but in HttpKernel a status code 500 is setted if the Exception is not a HTTP one.

@jeremyFreeAgent but AccessDeniedException is handled by the exception controller of the Security component when you are behind a configured firewall.

@stof so it is a bad practice to throw a AccessDeniedException in a controller outside the pattern of a configured firewall?

@jeremyFreeAgent careful, the exception dbu was referring to is an AccessDeniedHttpException not an AccessDeniedException. AccessDeniedHttpException extends HttpException which implements HttpExceptionInterface so the handleException function is supposed to take its status (403) and not send a 500...

@fgueguen True, that why I said:

I don't know if it is linked...

so it is a bad practice to throw a AccessDeniedException in a controller outside the pattern of a configured firewall?

yes. The AccessDeniedException is related to the Security component, asking it to check whether you could have a chance to authenticate with a higher level before giving you a 403 (if you are an anonymous or remembered user, it will ask you to authenticate instead).
If the Security system is not active on your URL, it makes no sense to trigger an exception of the Security system

I'm having a look at this during the Hackday at Madrid.

After poking around for a while, I cannot reproduce this bug. At least not as a generic bug with how the system handles HttpExceptions thrown inside event listeners. Wrote a couple of tests, implemented a listener to throw around some exceptions and, and all seems to work as intended.

I PR'd the tests, maybe someone else can figure out if there is some specific scenario where this bug happens.

played around with this again. i use a stock symfony 2.5 kernel and generated a fragment url, then curl that with the esi capability. i have security configured so that _fragment is not in the paths allowed by my user.

in prod (!) environment, i get this stack trace as response:

`

The only thing that looks suspect to me is handleException method in src/Symfony/Component/HttpKernel/HttpKernel.php. Except it's a 403 error, which would prevent the else clause from setting statusCode to 500. Unless something else is changing status code in-between I don't see anything that raises flags that this may be caused by the symfony package directly.

@dbu I just tried to reproduce this issue and I'm not experiencing the same behaviour (Symfony 2.6). Since I'm second person who can't reproduce it, please re-create your issue on a fork of Symfony SE and provide instructions how to trigger the error.

Sorry for not following up on this. i now tried this again. the problem is in symfony 2.3. can you try these steps?

composer.phar create-project symfony/framework-standard-edition fragment_issue 2.3
# say no to demo bundle, no need for a database
cd fragment_issue
app/console server:run

Then try to send a request with a non-safe method: curl -XPUT -v http://127.0.0.1:8000/app.php/_fragment?_path=_format%3Dhtml%26_locale%3Den%26_controller%3DAcme%253ADemoBundle%253ADemo%253Aindex

The problem also exists with symfony 2.5 but that is already past its support period.

@dbu yept, that did the job. Thanks, I'll be looking into this! The problem doesn't exist in >=2.6 anymore.

Closing as this issue isn't present in any maintained release.