Top Nav

Archive | Webservers

Test CORS with curl

Is your CDN returning the proper CORS headers? One way to test is with curl. Here’s a simple CORS request:

You should get a successful response that includes and “Access-Control-Allow-Origin” header.

And here’s a pre-flight request:

You should get a successful response that includes and “Access-Control-Allow-Origin”, “Access-Control-Allow-Methods”, and “Access-Control-Allow-Headers” headers.


Mixing Basic Auth And IP Access Controls

In some cases you might want to require HTTP Basic authentication to a site but allow specific IP addresses to skip the username/password. For Apache this can be configured with:

For nginx the configuration is:





Plesk 12.5 Protected Directories Break Nginx/PHP-FPM

On Plesk 12.5, when using PHP-FPM with Nginx there’s a problem with the way protected directories are implemented. Each protected directory creates a “location” block in the Nginx config that proxies to Apache. So protected directories are implemented in Apache only. Nginx just passes through to Apache.  This is not a great design choice in our opinion. Instead protected directories should be implemented directly in Nginx.

One of the side effects of the 12.5 implementation is that inside protected directories Apache handles PHP even if you have the domain configured to use Nginx with PHP-FPM. This is especially problematic if you have the entire site password protected. The “location /” block takes precedence over the “location *.php” block so the entire sites ends up using Apache instead going directly to PHP-FPM.

To get around this problem I do the following in Plesk:

  1. Create a protected directory for “/protected”.  Add users as needed.
  2. On the “Apache & nginx Settings” screen, add the following to the “Additional nginx directives” field:
  3. In your .htaccess file add:

The last step is important because we need both Apache and Nginx to enforce the protected directory.



Turn off Keep-Alive for directory

Recently had a problem where Chrome browsers were not fully downloading a large PDF document. The first few 100KB would download but then the document would stop loading.

After some debugging we concluded that Keep-Alive in Apache was creating the problem. We didn’t want to disable KeepAlive for the entire server so instead we added this line to the .htaccess file containing the PDF files:




MariaDB on CentOS 7 – “Error in accept: Too many open files”

By default is seems the soft and hard open files limits on MariaDB in CentOS 7 are 1024 and 4096 respectfully. You can see these limits by first getting the process ID:

And then looking at the limits in the proc filesystem:

You’ll see something like this:

Notice the numbers for “Max open files”.

If you run into problems with MariaDB failing and you see errors like this in the log:

Then you need to increase the open files limits by editing:

and adding this line:

to the “[Service]” section. Then reload the systemctl daemon:

and restart the MariaDB service:

Now the limit will be increased.  For example:

UPDATE: We’ve seen similar problems with nginx. The solution is similar … increase the limits for the nginx service.

UPDATE: As noted by Bastiaan Welmers in the comments, it better to copy the service control file then to edit: