Hesko

Когда речь заходит о запуске приложения в локальной среде, многие из нас прибегают к удобному инструменту – встроенному веб-серверу, доступному через php -S или artisan serve. Этот инструмент является прекрасным выбором для множества проектов, но он обладает своими особенностями, о которых важно помнить.

Одна из ключевых ограничений встроенного веб-сервера PHP заключается в том, что он оперирует только одним однопоточным процессом. Это значит, что приложение будет отдавать ответы одним за другим, и если будет “тяжёлый” запрос, то следующие после него запросы будут ожидать его выполнения. Это может стать проблемой, особенно если ваше приложение использует технологии, требующие одновременного обслуживания нескольких соединений, такие как SSE (Server-Sent Events).

Однако, не стоит отчаиваться и сразу устанавливать решения типа nginx. У PHP есть решение этой проблемы, которое доступно с версии 7.4.0, выпущенной еще в 2019 году.

Секрет заключается в использовании переменной окружения PHP_CLI_SERVER_WORKERS, которая позволяет указать количество воркеров для веб-сервера PHP.

Для пользователей фреймворка Laravel этот процесс очень прост, требуется только добавить значение в файл .env, например:

PHP_CLI_SERVER_WORKERS=4

APP_NAME="Laravel.su"
APP_ENV=local
APP_KEY=XXX-XXX-XXX

Однако, стоит отметить, что этот метод не будет работать для пользователей Windows. В этом случае вам придется прибегнуть к другим методам оптимизации производительности.

Сейчас (март 2024) переменная PHP_CLI_SERVER_WORKERS попрежнему считается экспериментальной, но я надеюсь, что она лишится этого статуса и будет с нами на постоянной основе.

После развертывания приложения на сервере одним из наиболее распространенных вопросов является настройка защищенного соединения через протокол HTTPS. Даже если приложение кажется работающим, могут возникнуть неожиданные проблемы с редиректами или смешанным контентом (Mixed Content: The page at '...' was loaded over HTTPS).

Как исправить и разобраться в причинах? Давайте рассмотрим, как настроить Laravel для работы по протоколу HTTPS.

Проверка настроек файла .env

Первым шагом следует убедиться, что значение переменной APP_URL в файле .env установлено корректно:

APP_URL = https://laravel.su/

В действительности параметр APP_URL не влияет на HTTP/HTTPS, но часто используется, например в ссылках.

Если значение верное, но проблемы с HTTPS все еще возникают, быстрым и ленивым решением будет принудительно указать использование HTTPS в сервис-провайдере вашего приложения. Вот пример кода, который активирует HTTPS только в случае, если среда выполнения приложения – production:

use Illuminate\Support\Facades\URL;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    if ($this->app->environment('production')) {
        URL::forceScheme('https');
    }
}

Почему возникают проблемы с HTTPS?

Чтобы понять причину возникновения этих проблем, давайте разберемся, каким образом фреймворк определяет протокол для работы. Ведь приложение может работать как на HTTP, так и на HTTPS. Ответ на этот вопрос прост: каким был запрос, такой же будет и ответ.

При обработке запроса Laravel захватывает данные и в дальнейшим работает с ними через объект. Это позволяет избежать работы с глобальными переменными типа $_POST или $_SERVER.

use Illuminate\Http\Request;

$request = Request::capture();

Класс Illuminate\Http\Request основан на компоненте symfony/http-foundation, который содержит метод isSecure, проверяющий, является ли текущий протокол безопасным. С помощью проверки переменной $_SERVER['HTTPS'] как не пустой и не равной 'off’. Этот механизм почти не менялся с первой версии Symfony.

Зная эту информацию мы можем проверить, что ваш веб-сервер настроен на передачу правильного значения для $_SERVER['HTTPS']. Если это не происходит автоматически, необходимо внести соответствующие изменения в конфигурацию сервера.

Настройка каждого веб-сервера (Apache, Nginx, Caddy) выходит за рамки Laravel, однако вы можете найти соответствующую информацию в документации используемого программного обеспечения.

Облачные сервисы и балансировщики

Как мы уже выяснили, если трафик идёт по незащищенному соединению, приложение также будет считать, что работает по HTTP. Но есть случаи когда обмен может совершаться между различными внутренними или облачными сервисами, где в HTTPS нет необходимости.

Для решения этой проблемы был добавлен механизм “Доверенных прокси”, который выполняется ещё до проверки $_SERVER['HTTPS']. Его настройку для 10.x версии Laravel можно встретить в App\Http\Middleware\TrustProxies.

Например, если вы используете Cloudflare с их динамическим списком IP-адресов, имеет смысл настроить “доверять всем”:

class TrustProxies extends Middleware
{
    /**
     * The trusted proxies for this application.
     *
     * @var string|array
     */
    protected $proxies = '*';

    // ...
}

Дополнительную информацию можно найти в документации.