<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - URL paths should not be normalized when encoded"
href="https://bugs.webkit.org/show_bug.cgi?id=144320#c16">Comment # 16</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - URL paths should not be normalized when encoded"
href="https://bugs.webkit.org/show_bug.cgi?id=144320">bug 144320</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=144320#c15">comment #15</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=144320#c14">comment #14</a>)
> > Updated patch to do the normalization or not depending on the platform. Also
> > removed the form data filename, as I'm not sure about that case. Darin, is
> > it correct to assume that PLATFORM(COCOA) means HFS?
>
> It’s not correct to assume that. Macs support NFS, for example.
>
> It’s true that most older Unix systems have filenames that are an arbitrary
> string of bytes; the typical restriction is simply that none of the bytes
> can be '\0' or '/'. But note that the string of bytes can’t necessarily be
> converted into a sequence of UTF-16 code points. There could easily be a
> filename that’s not a valid UTF-8 sequence. How would we handle that?
> </span >
So, that's another reason not to normalize filenames in URL, no?
<span class="quote">> When we are talking about URLs, what matters is the file system on the
> server, not on the client.</span >
Oops, of course, you are right.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>