pub fn is_dot_segment(segment: &str) -> boolExpand 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"));