Sometimes, when browsing Microsoft’s sites, you can run into some weird errors – like Bad Request – Request too long or sometimes even Connection refused. These errors are mostly caused by cookies. In this article, I am going to show you the most common causes and also tips on how to avoid these issues on your sites.
In this article we are going to take a look at options on how to deploy a standard PHP application to Azure App Service. This article is split into two parts – classical App Service running Windows and the new Docker-based App Service on Linux which recently got some really nice improvements towards PHP support.
cURL is one of the most common ways to make HTTP requests from PHP code. When you make regular http:// calls everything is alright, but when you decide to go with https://, you need to configure few things on App Service manually for it to work correctly.
There are many different articles on the internet about how to make an application faster when hosting it on Azure. This has been a real pain point with big PHP applications or applications which involve a lot if IO operations – like loading modules with Node.js. Recently, I was working with one startup and they approached me with a very interesting issue: Their Node.js application was running about 35x faster on Heroku than on Azure App Service and that is what actually made me to write this article.
When speaking of modern development nowadays, we can hear words like DevOps and as part of that, Continuous Integration (if you never heard about it, you can read more about it here). Anyways, today I am going to show you how to set up a build definition for a PHP project stored in Visual Studio Team Services and then the publication to an Azure Web App or a physical server.
During the last couple of weeks, users started noticing certain issues with an application that I develop on Microsoft Azure using PHP and Azure Web Apps. In general, the application is using an OAuth2 library to connect to a custom identity provider, the access token, refresh token and others are stored in $_SESSION. From the last sentence, you could have noticed two keywords – OAuth2 and refresh. The users started noticing an issue that after some time of working with the application (also the IdP was generating loads of useless token pairs), that they had to constantly relog. After turning on the logs, doing some diagnostics and trying to reproduce the issue, it was pretty clear – something fishy is going on with sessions.
One of the most pain points during PHP development is usually debugging for me. Quite frankly, I hate to run and debug PHP applications on my local machine, because when you move them somewhere else (to another environment) they sometimes don’t work and you have to do some more configuration (let’s ignore the fact that Docker or similar solutions can solve this on a decent level).