Verify Laravel Package

Getting Started

The package ships two halves that are easy to conflate: a pre-flight that decides whether a URL is worth submitting (canonical check, robots, redirects, host checks) and a submitter that performs the actual POST(s). 0.4.0 changes which HTTP client each half uses, so read that boundary first before writing any code.

Minimal path:

1. composer require the package and let Laravel discover it. 0.4.0 requires indexnowkit/core ^0.13; if you pin core explicitly in composer.json, bump it in the same commit or the adapter classes will resolve against the wrong version.
2. Publish the config and set the essentials — API key, the host(s) you own, and how the key file is served. Nothing in 0.4.0 changes these.
3. Look first at the verify.* block, not the submission settings. That is where this release lives: verify.transport, verify.timeout, verify.redirect, verify.max_redirects, verify.time_budget, verify.delay.
4. Run the package's check command once against your real config. The verify.transport line is no longer a warning — it now states which client does what (pre-flight vs. submission POSTs). Treat it as a description to read, not a problem to silence.
5. First real use case: dispatch a submission for a handful of URLs on one host, all genuinely canonical, and let the queue worker handle it. Then compare your job's visibility timeout against verify.time_budget — that ratio is the thing that bites people.

Implementation Patterns

Split your HTTP expectations along the release's new seam. The pre-flight always builds the PSR-18 client that core discovers, with max_redirects: 0 and verify.timeout. It ignores the client locator entirely. The submission POSTs still flow through the application's http.client. So: if you bind a proxied, instrumented, or logging client to http.client, it will observe POSTs and nothing else. If you need to influence pre-flight transport (proxy, custom TLS, test double), do it at the PSR-18 discovery layer, not through Laravel's container.

Size the queue job as delay + verify.time_budget < visibility timeout. verify.time_budget is now taken before the verify.delay waits, which is the correct reading of "budget": the delay counts against it. If you had previously shaved the budget down to compensate for the old overrun, that fudge is now double-counting — restore the budget and keep the delay explicit.

Adapters: call OptionalPackage::verify() directly. VerifyServices::package() still exists and delegates, with the same name, marker and feature word, but the package identity now lives in core. New adapter code should not load VerifyServices just to ask about the package; existing adapters keep working and can be migrated lazily.

Expect previously-dropped URLs to start submitting. A relative <link rel="canonical"> now resolves against <base href> (itself resolved against the page URL), the way a crawler does it. Pages that carry a <base> and were being discarded as "non-canonical" will now pass the check and reach the submitter. On a large site this is a volume change, so roll out and watch submission counts rather than assuming behaviour is unchanged.

Keep a canonical/redirect fixture set in tests. The class of bug fixed here — a refusal in the closed direction, silently dropping good URLs — is only visible if you assert on both outcomes: URL accepted, and URL rejected with a reason. A <base href> page with a relative canonical belongs in that fixture set permanently.

Gotchas and Tips

• A redirect-following http.client binding was silently weakening verification. Before 0.4.0 a client that followed redirects saw the final 200, which disabled verify.redirect, verify.max_redirects, the host check on redirect targets and loop detection without any error. After upgrading, those checks are live again. If you had such a binding, expect new rejections and new check output; this is a fix, not a regression, but it will look like one in dashboards.
• http.client is no longer a lever on pre-flight. Any comment, doc, or config note in your codebase claiming otherwise is now stale. Grep for it.
• verify.timeout only covers the pre-flight. Submission POST timeouts come from whatever http.client you bound; a slow IndexNow endpoint won't be bounded by verify.timeout.
• Don't panic-edit on the verify.transport line. It moved from warning to informational by design; the message distinguishes pre-flight from submission so you can tell a proxy on POSTs from the discovered client on pre-flight.
• IPv6 hosts in tests: RobotsCache::key() now strips [, ] and : so https://[::1] produces a PSR-16-safe key. Before this, a strict store rejected the key and the cache degraded to one fetch per process with a warning — if you saw repeated robots fetches against an IPv6 host, that was why, and it's fixed.
• Extension points that survive: the config verify.* surface, the http.client binding (POST side), and PSR-18 discovery (pre-flight side). Anything that reached into VerifyServices::package() for package identity is on a delegation path now — fine today, worth migrating.