![]() Make sure to use set or merge purposefully. Also any other response within our maintenance mode will have the same headers. This is a 100% replacement for the listener and reduced the time Symfony needs for a request (although I doubt that it's measurable). Header merge Access-Control-Allow-Methods "GET,POST,PUT,PATCH,DELETE,OPTIONS". Header merge Access-Control-Allow-Headers "Authorization,Accept-Language,Connection,Content-Type,Content-Length,Host,Origin,User-Agent" Header set Access-Control-Allow-Origin "*" But the application should not be reached in the maintenance mode, so we need to move this into the Apache configuration: # Cors With it, everything returned from Symfony has a header which allows my mobile app to call the API. It was also responsible to add the same headers on any exception. $response->headers->set('Access-Control-Allow-Headers', 'Authorization,Accept-Language,Connection,Content-Type,Content-Length,Host,Origin,User-Agent') $response->headers->set('Access-Control-Allow-Methods', 'GET,POST,PUT,PATCH,DELETE,OPTIONS') $response->headers->set('Access-Control-Allow-Origin', '*') Don't do anything if it's not the master request. Public function onKernelResponse(ResponseEvent $event): void Previously I had the following listener in my application: final class HeaderResponseListener implements EventSubscriberInterface In my case that was everything related to headers, especially Cors headers. Before we can build anything maintenance related, we need to see what we might need to move from our application to a configuration. The only layer between our application code and the Heroku load balancer is our server configuration. But this would mean that our application is triggered (which might have side effects) and that we need code within our application to handle the maintenance mode. The easiest approach (which is also the one I found all over the internet) would be to simple add a listener to your application (for example Symfony) and return a 503 Service Unavailable response for every request as soon as an environment variable is set. With those goals in mind, let's see how close we can get. Doesn't need a special handling for it within our application (no code that needs to be maintained).It's easy to configure (through a click in the web interface of the app or with changing one setting through the console).The request doesn't reach the application and therefore doesn't affect any work we might do while in maintenance mode.The Heroku maintenance mode has three advantages: ![]() This means we need to build the maintenance mode ourself. But there aren't any settings to configure the headers returned there and we can't do anything in our application as a request never reaches the application (by design). With it, we need to disable Cors headers of the requests, to not be canceled immediately. This is problematic when building an API which is used by a hybrid mobile app through a browser. But unfortunately it can't be customized any further than customizing the HTML page which is shown in the iFrame. With it, the dyno isn't reached and an iFrame with a maintenance HTML page is shown.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |