Why does actix-files return an error when serving a file that ends with a colon

[samu698]

I noticed this issue (svenstaro/miniserve#1450) in the miniserve crate, I searched for the root cause and i found that actix-files refuses to serve files having a colon at the end of any of its path segments

actix-web/actix-files/src/path_buf.rs

Lines 47 to 63 in e1da110

	} else if !hidden_files && segment.starts_with('.') {
	return Err(UriSegmentError::BadStart('.'));
	} else if segment.starts_with('*') {
	return Err(UriSegmentError::BadStart('*'));
	} else if segment.ends_with(':') {
	return Err(UriSegmentError::BadEnd(':'));
	} else if segment.ends_with('>') {
	return Err(UriSegmentError::BadEnd('>'));
	} else if segment.ends_with('<') {
	return Err(UriSegmentError::BadEnd('<'));
	} else if segment.is_empty() {
	segment_count -= 1;
	continue;
	} else if cfg!(windows) && segment.contains('\\') {
	return Err(UriSegmentError::BadChar('\\'));
	} else if cfg!(windows) && segment.contains(':') {
	return Err(UriSegmentError::BadChar(':'));

I looked at the older commits to see what was the reason for implementing this filter and I found this

actix-web/src/recognizer.rs

Lines 98 to 143 in d8f27e9

	/// Creates a `PathBuf` from a path parameter. The returned `PathBuf` is
	/// percent-decoded. If a segment is equal to "..", the previous segment (if
	/// any) is skipped.
	///
	/// For security purposes, if a segment meets any of the following conditions,
	/// an `Err` is returned indicating the condition met:
	///
	/// * Decoded segment starts with any of: `.` (except `..`), `*`
	/// * Decoded segment ends with any of: `:`, `>`, `<`
	/// * Decoded segment contains any of: `/`
	/// * On Windows, decoded segment contains any of: '\'
	/// * Percent-encoding results in invalid UTF8.
	///
	/// As a result of these conditions, a `PathBuf` parsed from request path parameter is
	/// safe to interpolate within, or use as a suffix of, a path without additional
	/// checks.
	impl FromParam for PathBuf {
	type Err = UriSegmentError;
	fn from_param(val: &str) -> Result<PathBuf, UriSegmentError> {
	let mut buf = PathBuf::new();
	for segment in val.split('/') {
	if segment == ".." {
	buf.pop();
	} else if segment.starts_with('.') {
	return Err(UriSegmentError::BadStart('.'))
	} else if segment.starts_with('*') {
	return Err(UriSegmentError::BadStart('*'))
	} else if segment.ends_with(':') {
	return Err(UriSegmentError::BadEnd(':'))
	} else if segment.ends_with('>') {
	return Err(UriSegmentError::BadEnd('>'))
	} else if segment.ends_with('<') {
	return Err(UriSegmentError::BadEnd('<'))
	} else if segment.contains('/') {
	return Err(UriSegmentError::BadChar('/'))
	} else if cfg!(windows) && segment.contains('\\') {
	return Err(UriSegmentError::BadChar('\\'))
	} else {
	buf.push(segment)
	}
	}
	Ok(buf)
	}
	}

I'm curious to know why this check is in place and if it is possible to remove or change it to allow serving files starting/ending with these characters

[JohnTitor]

I'm not the original author so this is just my thought, but colon has a special meaning/not allowed in some context even on Unix, e.g. on some applications or filesystems. The actix-web application may cause unwanted behavior because of it.
I think this is reasonable for compatibility and portability, and anyway it should be unsual usecase in the real world I believe.