On Wed, 10 Sep 2008 03:54:00 -0000
[EMAIL PROTECTED] 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/
