You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that Windows uses file URLs with '@' (U+0040) characters in their host parts, such as file://webdavserver.net@ssl/a.pdf.
However, according to my understanding, file://webdavserver.net@ssl/a.pdf is an invalid URL in the URL Standard because '@' is considered a forbidden host code point.
To ensure compatibility with Windows file URLs, should we consider allowing the '@' character in the host part of file URLs?
I'd appreciate hearing opinions of the URL Standard folks on this matter.
The text was updated successfully, but these errors were encountered:
It seems reasonable to allow, but I wonder if it would be possible for Chromium to determine the complete set of changes needed for it to not have platform-divergent behavior. At least I suspect that making them all at once would allow for an easier rollout.
A single @ in the authority section (username, password, hostname, port) generally delimits the credentials from the hostname.
Let's take any other URL scheme, e.g. HTTP: http://webdavserver.net@ssl/
"webdavserver.net" would be the username
"ssl" would be the hostname
Which is clearly not what the reporter wants to happen.
What's more, this has been the accepted interpretation for at least the last 30 years (going back to RFC-1738). I doubt many URL parsers are going to interpret file://webdavserver.net@ssl/ as having a hostname containing an @ sign, so the output of the URL parser must keep the @ escaped in order to properly encode its understanding of the URL components. file://webdavserver.net%40ssl/ is semantically correct.
I think the actual problem is that hostnames in file URLs are not able to contain percent-encoding. I looked in to this in depth a while back, and found that:
UNC server names can contain spaces, which obviously must be escaped. Chromium even has test cases for this (see linked issue below), so you'll probably hit this sooner or later.
Windows allows pre-canonicalised paths, which are expressed using UNC syntax with the hostname "?" (e.g. \\?\C\SomePath). These cannot be expressed using file URLs because the hostname would have to be %3F.
(Reported in https://crbug.com/1502849)
It appears that Windows uses file URLs with '@' (U+0040) characters in their host parts, such as
file://webdavserver.net@ssl/a.pdf
.However, according to my understanding,
file://webdavserver.net@ssl/a.pdf
is an invalid URL in the URL Standard because '@' is considered a forbidden host code point.To ensure compatibility with Windows file URLs, should we consider allowing the '@' character in the host part of file URLs?
I'd appreciate hearing opinions of the URL Standard folks on this matter.
The text was updated successfully, but these errors were encountered: