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
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.