httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r607468 - /httpd/httpd/branches/2.2.x/STATUS
Date Sat, 29 Dec 2007 20:44:35 GMT
niq@apache.org wrote:
> Author: niq
> Date: Sat Dec 29 11:50:11 2007
> New Revision: 607468
> 
> URL: http://svn.apache.org/viewvc?rev=607468&view=rev
> Log:
> Propose, veto.
> 
> Modified:
>     httpd/httpd/branches/2.2.x/STATUS
> 
> Modified: httpd/httpd/branches/2.2.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=607468&r1=607467&r2=607468&view=diff
> ==============================================================================
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Sat Dec 29 11:50:11 2007
> @@ -88,6 +88,11 @@
>        wrowe notes; as nice as customization might be, this mirrors the behavior
>        or all RFC conformant browsers, and additional customization can come
>        as a new feature in the future.
> +      -1: niq.  We cannot label FTP directory listings as ISO-8859-1 unless
> +                we ensure they really are (e.g. some backend platforms will
> +                give us UTF-8).  Also mod_dav embeds r->uri in the response:
> +                we would need to URL-escape that before HTML-escaping it
> +                to ensure that it's ISO-8859-1-compatible.

I think you missed the point, by RFC 2616, these *are* to be interpreted
as ISO-8859-1 as they are presented today.  If we presented them as some
other content type, it would not have this implication.

3.4.1 Missing Charset

    Some HTTP/1.0 software has interpreted a Content-Type header without
    charset parameter incorrectly to mean "recipient should guess."
    Senders wishing to defeat this behavior MAY include a charset
    parameter even when the charset is ISO-8859-1 and SHOULD do so when
    it is known that it will not confuse the recipient.

    Unfortunately, some older HTTP/1.0 clients did not deal properly with
    an explicit charset parameter. HTTP/1.1 recipients MUST respect the
    charset label provided by the sender; and those user agents that have
    a provision to "guess" a charset MUST use the charset from the
    content-type field if they support that charset, rather than the
    recipient's preference, when initially displaying a document. See
    section 3.7.1.

3.7.1 Canonicalization and Text Defaults

[...]
    The "charset" parameter is used with some media types to define the
    character set (section 3.4) of the data. When no explicit charset
    parameter is provided by the sender, media subtypes of the "text"
    type are defined to have a default charset value of "ISO-8859-1" when
    received via HTTP. Data in character sets other than "ISO-8859-1" or
    its subsets MUST be labeled with an appropriate charset value. See
    section 3.4.1 for compatibility problems.

Mime
View raw message