httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: svn commit: r693697 - in /httpd/sandbox/mod_valid_utf8: ./ README mod_valid_utf8.c
Date Wed, 10 Sep 2008 09:41:27 GMT
On Wed, 10 Sep 2008 03:54:00 -0000
ianh@apache.org wrote:

> Author: ianh
> Date: Tue Sep  9 20:53:59 2008
> New Revision: 693697
> 
> URL: http://svn.apache.org/viewvc?rev=693697&view=rev
> Log:
> initial check in.
> this filter validates that the incoming request contains valid UTF8
> characters.

Why?

Last time I looked, incoming charsets were indeed a problem area,
but a browser submitting an HTML form would de-facto use the
same charset as the form.  Not necessarily utf-8.

Not to mention the many other use cases for sending non-utf8 data.

> +static char* validate_buffer( apr_pool_t *p,  const char* inbuf,
> apr_size_t* length) +{

Looks like a potential util_ function.  Cousin to both apr_uri
and apr_xlate.

> +        if (inbuf[i] == '%' ) {
> +            if ((i < len -2 ) && ishexnumber( inbuf[i+1]) &&
> ishexnumber( inbuf[i+2])) {

... is all very well, but

> +            else {
> +                buffer[j++]=inbuf[i++];
> +            }

Shouldn't that at least be marked /* FIXME */
where you potentially let through the chars you're
supposed to block ?


> +    ap_hook_pre_connection(utf8_pre_conn, NULL, NULL,
> APR_HOOK_MIDDLE); +
> +    ap_register_input_filter(utf8_filter_name, utf8_in_filter, NULL,
> +                             AP_FTYPE_NETWORK - 1);

Huh?  Isn't that before mod_ssl, let alone mod_deflate, mod_charset?
And no excape path for binary data either.  It'll cripple any server
with it loaded!


-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Mime
View raw message