Pass a request from a web server to Magento

When a browser sends a request to your Magento store, several things happen before your PHP code even starts executing. Understanding this entry process helps you debug more effectively by seeing how requests actually flow through your servers.

Web server

The first thing that happens is your request hits a web server - typically Nginx or Apache, though it could also be a load balancer or proxy server. This server receives the HTTP request and determines which application should handle it.

For a Magento store, your web server config contains rules that map your domain to your Magento installation directory. These rules typically route requests to the correct application, block access to sensitive files, configure caching headers, and handle static files directly.

Since all eCommerce storefronts use HTTPS, this server also handles SSL termination. It decrypts the encrypted HTTPS traffic from the visitor's browser and processes the now-unencrypted request. In some configurations, it might re-encrypt the request when passing it to internal services.

Here's a sample Nginx config file that shows a typical SSL configuration:

server {
  listen 80;
  return 301 https://$host$request_uri;
}

server {
  listen [::]:443 ssl http2 ipv6only=on;
  listen 443 ssl http2;

  ssl_certificate /etc/nginx/certs/nginx.crt;
  ssl_certificate_key /etc/nginx/certs/nginx.key;

  set $MAGE_ROOT /var/www/example.com;
  
  include /var/www/example.com/nginx[.]conf;
}

Notice that the end of this file includes another Nginx config file, which typically contains settings specific to Magento application handling.

Pro note: The [.] notation in the file include is a glob pattern that matches a single character (in this case, a period). When Nginx uses glob patterns in include directives, it silently continues if no files match, making this a neat trick to conditionally include nginx.conf only if it exists (without causing errors if it doesn't).

Secure entry point

When the web server determines a request should go to Magento, it routes it to pub/index.php - Magento's public entry point.

Requests are routed to the pub directory as a security measure. By exposing only this directory to the public internet, you keep your core application files, configuration, and composer dependencies private.

If you accidentally configure your web server to expose the root project directory, you could reveal sensitive files that should never be directly accessible to the public, opening up potential security vulnerabilities.

Here's part of the Nginx config file provided by Magento:

# ...

root $MAGE_ROOT/pub;

# ...

location / {
    try_files $uri $uri/ /index.php$is_args$args;
}

# PHP entry point for main application
location ~ ^/(index|get|static|errors/report|errors/404|errors/503|health_check)\\.php$ {
    try_files $uri =404;
    fastcgi_pass   fastcgi_backend;
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;

    fastcgi_param  PHP_FLAG  "session.auto_start=off \
 suhosin.session.cryptua=off";
    fastcgi_param  PHP_VALUE "memory_limit=756M \
 max_execution_time=18000";
    fastcgi_read_timeout 600s;
    fastcgi_connect_timeout 600s;

    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;
}

# Banned locations (only reached if the earlier PHP entry point regexes don't match)
location ~* (\\.php$|\\.phtml$|\\.htaccess$|\\.htpasswd$|\\.git) {
    deny all;
}

# ...

Pro note: The location lines use regular expression syntax to specify exactly which PHP files to target or not target. It only allows Magento's official entry points like index.php, get.php, and a few others. This is a security feature and will make any other PHP files in your Magento installation (like uploaded files or internal libraries) blocked from being executed, preventing potential security vulnerabilities.

Once the request reaches pub/index.php, PHP takes over, and Magento's code processes the request further.