Victor Wagner wrote:
On 2007.12.29 at 11:41:48 -0600, William A. Rowe, Jr. wrote:
Nick Kew wrote:
>From 2.2.x/STATUS:
* Various modules: Add explicit charset to the output of various
modules to work around possible cross-site scripting flaws affecting
web browsers that do not derive the response character set as required
by RFC2616.
Two comments on that: the first trivial, the second more serious:
1. Is ISO-8859-1 right for these? Sure, it's not wrong (unless
as in (2) below), but why not label it as plain ASCII?
They are all text/html. RFC2616 clearly defined them as ISO-8859-1
in the absence of any other charset tag.
But in pratice lot of people use sometihng other. For filenames as well.
Which is beyond the point of this discussion; moronic utf7 autodetection
puts us in the position of having to to reiterate what the RFC said in
the first place. So my sympathies /don't/ lie with confusing autodetect.
I think that as modern trend in operating system distributions is going
to use some version of Unicode for filesystems (UCS2 in NTFS, Utf8 in
most modern Linux distributions) utf-8 is much more sensible default.
Keep in mind, the visual representation may be wrong, but the actual URL's
presented will be correct in any case! These are escaped.
Since FTP doesn't provide us a clue of what flavor is which, for the
purpose of a proxy ftp representation, we'll be adding a directive that
you can apply site-by-site. Or globally, if you are convinced that your
FTP sites are mostly/nearly all utf8. That's fine.
But the ability to deflect autodetection of ftp proxy index pages from utf7
is a pretty narrow scope, and I believe Joe's patch has it. The new feature
isn't necessary for the next release. Although it would be nice, the idea
was to avoid holding anything up.
Bill
