You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ni...@apache.org on 2007/12/29 20:50:13 UTC
svn commit: r607468 - /httpd/httpd/branches/2.2.x/STATUS
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.
* mod_proxy_balancer: Prevent crash in balancer manager if invalid balancer
name is passed as parameter.
@@ -169,6 +174,11 @@
PR 39727
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_deflate.c?r1=580598&r2=607219&pathrev=607219
+1: niq, wrowe
+
+ * mod_dav: Fix evaluation of If-Match * and If-None-Match * conditionals.
+ PR 38034
+ http://svn.apache.org/viewvc?view=rev&revision=607466
+ +1: niq
PATCHES/ISSUES THAT ARE STALLED
Re: svn commit: r607468 - /httpd/httpd/branches/2.2.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
Re: svn commit: r607468 - /httpd/httpd/branches/2.2.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.