Laravel Http Client Default Options Laravel Package

Getting Started

v2.0.2 adds HTTP client event support, so the package's outbound requests are now observable through Laravel's standard Illuminate\Http\Client\Events\* lifecycle. That is the headline change and the reason to move to this version.

Minimum steps:

1. composer update to pull v2.0.2 and confirm the constraint in composer.json resolves (composer show <vendor>/<package>).
2. Check for a new config key — this feature is usually gated behind a flag (e.g. 'events' => ['enabled' => true]). Run php artisan vendor:publish --tag=<package>-config and diff against your existing published config rather than overwriting it.
3. Clear caches after upgrading: php artisan config:clear && php artisan event:clear (or optimize:clear).
4. Register one listener in app/Providers/EventServiceProvider::$listen against Illuminate\Http\Client\Events\ResponseReceived and log the request URL plus status — that single line is your first proof the feature is live.

Where to look first: the package's service provider (to see whether listeners are registered unconditionally or only when config is enabled), the published config file, and the package CHANGELOG/README section on events. Then grep the package source for RequestSending/ResponseReceived to confirm exactly which events it emits versus merely consumes.

First use case: an outbound-call audit log. A single listener on RequestSending + ResponseReceived + ConnectionFailed gives you start/finish pairing, latency, and failure visibility for every call the package makes — without touching the package internals.

Implementation Patterns

Correlation IDs across the request lifecycle. Generate an ID in a RequestSending listener, stash it on a Context (or a Request macro), and pick it up in ResponseReceived. Since RequestSending receives the Request object, this is the natural place to attach headers if the package exposes the request for mutation.

Structured logging over Log::info strings. Emit one JSON line per completed call (method, host, path, status, duration_ms, correlation_id). Keep the response body out of the log — capture length or a hash instead.

Metrics and alerting. Increment counters per status class in ResponseReceived, and treat ConnectionFailed separately — it is a distinct failure mode (DNS, TLS, timeout) and does not fire on 4xx/5xx. Wire these into your existing Prometheus/StatsD/Telescope pipeline rather than building a parallel dashboard.

Retry and circuit-breaker telemetry. If the package retries internally, listening to events is the cheapest way to count attempts per logical operation. Count RequestSending events against a business-level ID to distinguish "one call retried three times" from "three calls."

Test-time interception. Pair Http::fake() (to stub the package's outbound calls) with Event::fake([ResponseReceived::class]) when you only care that the event fired. For assertions, prefer Event::assertDispatched with a closure inspecting the request URL — it survives body changes.

Feature-scoped enablement. If events are opt-in, enable them only in the environments where you need them (staging/production) and keep them off in local test suites where the extra listener overhead and log noise slow runs.

Extension points. Beyond listeners, check whether the package exposes a resolved HTTP client you can ->withMiddleware() or ->beforeSending() on. Events are the low-coupling option; middleware is the option when you need to mutate the request.

Gotchas and Tips

• Events only cover the Laravel HTTP client. Calls made through a raw Guzzle client, a third-party SDK with its own transport, or curl directly will not appear. Do not assume the event log is a complete outbound traffic record.
• RequestSending fires before the wire. It gives you no status, no duration, and no response — pairing it with a completion event requires a correlation key (URL + timestamp, or a request header you inject).
• 4xx/5xx do not fire ConnectionFailed. A 500 arrives as ResponseReceived with a failing status. If your alerting only watches ConnectionFailed, you are blind to upstream errors.
• Response body consumption. ResponseReceived hands you a response whose body may already be read; calling ->body() in a listener can interfere with the package's own handling. Log ->status() and ->header('Content-Length') unless you have verified body access is safe.
• Double logging. If the package also ships a built-in logger, enabling both your listener and the package logger produces duplicate lines. Pick one and disable the other in config.
• Config caching in production. A newly published config key is invisible until config:cache is rebuilt. Symptom: the feature works locally, silently does nothing in production.
• Event::fake() swallows real dispatch. Any test that fakes events will pass event assertions but may mask missing listener registration; keep one integration test that lets real events through.
• Listener exceptions abort the flow. A throwing listener on ResponseReceived can surface as an error from the package's own call site, misattributing the failure. Wrap listener bodies in try/catch and log rather than throw.
• Version pinning. Since v2.0.2 is the first release carrying this capability, pin to ^2.0.2 if you depend on it; ^2.0.0 will resolve to versions that lack the feature.
• Debugging checklist when nothing fires: confirm the config flag, confirm config:clear, confirm the event class name matches your installed Laravel version (the Illuminate\Http\Client\Events namespace moved during Laravel 8.x), and confirm the package's client is the one actually making the call.