HTTP Methods and Required Logpush Fields

What the HTTP methods card shows

On every Path detail page, the HTTP methods breakdown shows how requests to that path split by method: GET, POST, PUT, etc. Colour-coded:

• Green — read-only (GET, HEAD, OPTIONS)
• Amber — mutating (POST, PUT, PATCH, DELETE)
• Red — (no method) — Logpush didn't supply a method for those requests

Why this matters

Different attacks prefer different methods. Some real-world patterns:

• Gift-card enumeration — a burst of POSTs on a redemption endpoint from many networks in a short window is almost always enumeration.
• Password-reset spam / account enumeration — mostly POST on the reset endpoint from distributed residential IPs plus datacentre egress.
• Form-probing — scrapers load the form (GET) to extract the token template before submitting (POST). A sudden shift from mostly-GET to mostly-POST on a submit endpoint can precede active exploitation.
• Scanning / fuzzing — high GET volume on endpoints that shouldn't be GET-accessible.

Checking your detector coverage

You don't have to memorise which field feeds which feature:

• Source detail page → coverage panel — shows which key fields your Logpush job is actually delivering and which detectors are inactive because a field is missing.
• Rules page → "requires field" badge — any rule that depends on a missing field is flagged in place.
• Overview banner — if the bot-score field is absent, a banner on the Overview says so, because several bot detectors depend on it.
• Sources list → freshness pill — Live / Delayed / Stale at a glance, so you can see the feed is healthy before trusting the data.

Fixing "(no method)"

If the HTTP methods card on a path shows a large red (no method) bar — especially 100% — it means the Logpush job for your source isn't shipping the ClientRequestMethod field.

Edit the Logpush job's field selection (via the CDN Zones API for SFCC, or your Cloudflare dashboard for a direct zone), tick ClientRequestMethod, and save. The next batch (within about 5 minutes) will start including the method. Historical data from before the fix will continue to show "(no method)" until it ages out.

The full required-fields list

Logpush is opt-in per field. The following fields should all be selected on your job config; missing any of them causes specific Edge features to degrade.

Field	What breaks without it
EdgeStartTimestamp	Ingest fails entirely — this is required
ClientIP	IPs page, Unique IPs column, forensic IP discovery
ClientASN	Offenders page and most detectors
ClientCountry	Country-scoped baselines, world map
ClientRequestPath / ClientRequestURI	Paths page, path-based detectors
ClientRequestMethod	HTTP methods card, Method Shift detector
ClientRequestUserAgent	UA families, UA Rotation and stale-browser detectors
EdgeResponseStatus	Status classes, 499 Rate detector
EdgeResponseBytes	Bytes columns everywhere
OriginResponseDurationMs	Origin Latency Spike detector, origin-latency diagnostics. SFCC renamed this from the legacy OriginResponseTime; only the new name is accepted.
CacheCacheStatus	Cache breakdown, Cache Bypass detector
EdgeColoCode	Data Centres panel
BotScore	Bot Score detector, Bots & agents page
BotScoreSrc	Verified-crawler and impersonation detection on the Bots & agents page
ClientRequestReferer	Channel attribution on the Channels page — organic and referral arrivals cannot be told apart from direct without it
ClientRequestHost	Same-site referrer suppression on the Channels page. Without it, navigation within your own site counts as referral arrivals and the Referral numbers inflate badly — the Channels page shows a banner when this field is missing
ClientSSLProtocol	TLS Weak Protocol detector
SecurityActions (SFCC) / FirewallMatchesActions (direct zone)	Challenge Solving detector, firewall-action panels

If a detector or panel isn't populating as expected, the first thing to check is the coverage panel on the source detail page.

Optional enrichment fields

Beyond the fields the detectors need, three optional Logpush fields unlock extra detail on the Bots & agents page. Add them to your job's field list the same way as any other field:

• EdgeResponseContentType — powers the "What it fetched" split in each bot's drill-down (pages vs data vs images vs assets). Available to every merchant, including bundled eCDN.
• BotDetectionIDs — Cloudflare Bot Management's stable detection identifiers per request, captured for future corroboration of bot identity. Available on bundled eCDN where the zone carries bot-management signal.
• VerifiedBotCategory — Cloudflare's crawler category labels. Not available on bundled SFCC eCDN zones (the field is rejected by the CDN Zones API); it works only on O2O or direct Cloudflare zones, where it renders as category chips on the Bots & agents page.

Missing optional fields never disable a detector; the related panels simply stay empty until the field arrives.