ParseURL documents that a duration query parameter is disabled with a value <= 0:

to disable a duration field, use value less than or equal to 0; to use the default value, leave the value blank or remove the parameter

That only works for plain integers. queryOptions.duration() returns the -1 disable sentinel in the integer branch, but a duration written with a unit goes through time.ParseDuration and is returned as-is, so a zero value with a unit is not disabled and falls through to the default:

read_timeout=0          -> ReadTimeout=0   (disabled)
read_timeout=0s         -> ReadTimeout=3s  (default)
conn_max_idle_time=0    -> ConnMaxIdleTime=-1  (disabled)
conn_max_idle_time=0s   -> ConnMaxIdleTime=0   (30m default after init)

(ReadTimeout values are shown after init(), which maps the -1 sentinel to the runtime no-timeout value.)

The fix applies the same <= 0 check in the ParseDuration branch so 0s disables the field like 0 already does. Negative values with a unit (-1s) are normalized to the same -1 sentinel for consistency; those already disabled at runtime since deadline() treats any timeout <= 0 as no deadline, so that part is parse-level consistency rather than a behavior change.

Added two conn_max_idle_time cases (0s, -1s) to TestParseURL; both fail before the change and pass after. go vet ./..., gofmt, and go build ./... are clean. The server-backed suite needs Docker so I did not run it, but the change is confined to URL parsing and is covered by TestParseURL.