Skip to main content

is_dot_segment

Function is_dot_segment 

Source
pub fn is_dot_segment(segment: &str) -> bool
Expand description

Whether segment is exactly . or ...

Unlike ordinary path characters, a literal ./.. segment is not neutralized by percent-encoding: . is an unreserved character (RFC 3986), so urlencoding::encode leaves it untouched, and the URL parser’s dot-segment removal (RFC 3986 §5.2.4) still collapses it after encoding — %2E decodes back to . before that normalization runs. A registry-fetch URL built as {base}/{prefix}/{name} (no fixed suffix after name) must reject a name/path segment satisfying this predicate rather than encode it, since encoding alone does not stop the collapse (#341, #349).

Shared by deps-npm’s scope/package segment guard and deps-dart‘s package-name guard — both ecosystems’ registry APIs key a fetch on a bare, suffix-less path segment.

Scope: this predicate (and the #365 regression sweep built around it) guards registry-fetch URL builders — the sink is a request this process actually dereferences, so a retargeted URL can make it fetch attacker-chosen data. It deliberately does not extend to a “docs link”/package_url-style builder (the per-ecosystem hover/display link, e.g. deps_cargo::crate_url, deps_go::package_url): those interpolate the name into a link rendered in hover text and never fetched by this process, so an unrejected ./.. name there produces at worst a misleading same-host link (the registry’s package-listing root), not a traversal off-host (#379).

§Examples

use deps_core::lsp_helpers::is_dot_segment;

assert!(is_dot_segment(".."));
assert!(is_dot_segment("."));
assert!(!is_dot_segment("left-pad"));