follow up to #1113, split out as suggested in this comment. this only blocks . and .. path segments, no encoding changes.

what's happening

url paths work like folders, and .. means "go up one level". fetch resolves that before sending, so an id of . or .. (or one containing ../) takes the request to a different endpoint:

• emails.cancel('..') sends POST /cancel
• domains.remove('../api-keys/KEY_ID') sends DELETE /api-keys/KEY_ID, which is the delete api key endpoint

if an app passes user input as an id, that lets a call escape its own endpoint.

the fix

fetchRequest now checks the path and returns an invalid_parameter error without sending anything if any segment is . or ... it also catches the encoded forms like %2E%2E, since url parsing treats those as dot segments too. it returns the error instead of throwing, same as the other input checks in the sdk.

nothing that works today changes. a dot segment always ended up on the wrong endpoint, and ids are still sent exactly as passed, so values that are already encoded keep working. ids that just contain dots (..., john.doe@example.com) go through as normal.

tests

• has-dot-segment.spec.ts: detects . / .. and the encoded forms, ignores the query string and fragment, allows ... and dotted emails
• resend.spec.ts: ., .. and ../api-keys/key-id return invalid_parameter and no request is made, ... still goes through

verified

built the sdk from the current release and from this pr, pointed both at a local http server via baseUrl, and logged the request that actually arrived:

Summary by cubic

Rejects request paths containing . or .. segments so user-supplied IDs can no longer redirect a request to another endpoint. fetch resolves dot segments before sending, so emails.cancel('..') was hitting POST /cancel and domains.remove('../api-keys/KEY_ID') was hitting the delete API key endpoint.

fetchRequest now returns an invalid_parameter error without sending anything when any path segment is . or .., including percent-encoded forms like %2E%2E. IDs that merely contain dots (..., john.doe@example.com) are unchanged.

^{Written for commit 2fef573. Summary will update on new commits.}