In ZAP's `spider` job, what does `handleParameters` actually control - and what does it not?

## What the option is wired to There are three values, spelled `use_all`, `ignore_value` and `ignore_completely` in an automation plan and in upper case in the add-on's own enum. It is tempting to read them as a statement about which parameters matter. They are not. **The option feeds exactly one thing: the string the spider uses to recognise a URL it has already visited.** The spider keeps a set of resource identifiers. Before it creates a task for a discovered resource it builds an identifier and checks the set; a hit means the resource is dropped with a "already visited" note and no request is sent. The identifier is not just a URL. It is the **request method**, then the cleaned URI representation this option shapes, then a canonical rendering of the headers the resource was found with, then a normalised form of the body. That last detail explains behaviour people find surprising: the same path reached by a link and by a form POST are two visits, and two POSTs to one action with different bodies are two visits as well. ## The three values | value | what survives into the visited key | effect on the crawl | |---|---|---| | `use_all` (default) | the whole URI, query string and all | every distinct value pair is a new page; maximum coverage, unbounded growth | | `ignore_value` | the path plus the parameter **names** | one visit per parameter *shape*; `?sort=asc` and `?sort=desc` collapse | | `ignore_completely` | the path only | one visit per path; the entire query dimension disappears from the crawl | The add-on's own shipped plan template describes the option in precisely these terms - how query string parameters are used when checking if a URI has already been visited - so the documentation is not the source of the confusion. ## What it is not - It does **not** decide which parameters an attack phase later exercises. That is a separate configuration on a separate component, and setting this option will not turn cookie or header testing on or off. - It does **not** strip the query from the requests the spider sends. A URL that was discovered is requested as it was found. What changes is whether a *second* URL differing only in its query is recognised as already seen. - It does **not** act alone. Depth, maximum children per node and maximum duration are separate brakes, and on a large parameterised site you usually need this option *and* one of those. ## Choosing it in a pipeline 1. **Start at the default and measure.** If a crawl finishes well inside its duration limit and the URL count looks like the application, leave `use_all` alone - it gives the richest history for anything that runs afterwards. 2. **Move to `ignore_value` when the count is dominated by one parameter.** Faceted search, pagination, sort orders, calendars and session-scoped tokens in the query are the usual culprits. You keep one representative request per parameter shape. 3. **Reserve `ignore_completely` for smoke-shaped runs.** It is cheap and predictable, and it is the setting most likely to make a later phase miss something, because only one sample per path ever reaches history. ## The knock-on effect that is easy to miss Everything downstream works from what the crawl recorded. Collapse the query dimension and a defect that only appears for one parameter value is not "rated low" - it is **absent**, because no request that would have revealed it was ever made. Conversely, leaving `use_all` on a site that mints parameters will burn the whole crawl budget in one corner of the application and leave the rest unvisited by the time a limit finally stops the run - or leave it running indefinitely if you set no duration or children limit at all. Both failure modes produce a run that completes normally. Neither announces itself. The way to tell them apart is to look at how many URLs the crawl added and where they clustered, not at whether the job reported success. ## The interview shape An interviewer asking this is usually checking one thing: whether you know the difference between a **discovery** control and an **attack** control. A candidate who answers "it decides which parameters get tested" has merged two phases that are configured separately, run on different engines and fail in different ways. Say what the option keys, say what it changes about the request stream, and then say what it does not touch.