context hash: original url clash with symfony

[dbu]

it seems the x-original-url is not a good choice, as symfony looks at that header.

should we go for x-url-backup or x-fos-original-url?

[dbu]

the plus of x-original-url would be that we do not need a route to avoid a 404. the bad is that the context hash would not be created and not be cached for 404 urls. this means that 404 will not be cached and create lots of hash lookup requests.

[ddeboer]

Can you elaborate a bit? I thought we didn't need a route for the hash request because our listener handles that request (and not some controller). If this doesn't work, we may have to give our listener priority over Symfony's routing listener.

[dbu]

our listener never would have triggered except when the x-original-url happens to point to a route that is served by symfony. essentially that means that for existing urls we accidentally get a hash (if the user does have access to the originally requested url) but would get forbidden for other originally requested urls and 404 for the hash if the requested url does not exist.

symfony security depends on the routing being done, and the user context depends on security to be available obviously. so we need to wait until after that happened, meaning we can

• try to listen to the kernel exception of route not found and replace the outcome
• provide a dummy route entry so there is no 404 and keep the listener
• provide a controller with the route and handle the hash request in there

i think the option to rely on symfony actually looking at x-original-url if that is present is a bad idea. it breaks in some situations (route not found, route forbidden for this user by the security configuration).

[stof]

I agree with @dbu. We should provide a route for the hash url to allow running our code after the RouterListener, and use a header which does not conflict with IIS rewrite rules.

[ddeboer]

All right, let's opt for @dbu's second solution, and not use the X-Original-Url header.