httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Found bug in multipart parser
Date Sat, 26 Jun 2004 01:03:19 GMT
Jean-Fran├žois Meessen <jfm@n-tech.be> writes:

[...]

> In the parser function split_on_bdry, if a partial match is detected just 
> before a bucket boundary and a real boundary just after it, the parser
> fails to detect it.  If the boundary string is for example
> \r\n----------123456 and the form data contains:
> The end of the file content...\r\n[BUCKET BOUNDARY]\r\n----------123456
> The \r\n before bucket boundary will be a partial match and the
> following \r\n will be interpreted as a mismatch (because the first 2
> chars have already been matched). In this case, the parser will not
> detect the boundary. 

Thanks alot!  Your patch looks correct to me, although there's
another way to fix apreq_parsers.c without the gotos:

Index: src/apreq_parsers.c
===================================================================
RCS file: /home/cvs/httpd-apreq-2/src/apreq_parsers.c,v
retrieving revision 1.49
diff -u -r1.49 apreq_parsers.c
--- src/apreq_parsers.c 21 Jun 2004 17:49:18 -0000      1.49
+++ src/apreq_parsers.c 26 Jun 2004 00:49:30 -0000
@@ -711,7 +711,7 @@
         else
             idx = apreq_index(buf, len, bdry, blen, APREQ_MATCH_PARTIAL);

-        if (idx > 0)
+        if (idx >= 0)
             apr_bucket_split(e, idx);

         APR_BUCKET_REMOVE(e);


It's a simpler patch, but is less efficient than yours
because we're basically wasting an extra pattern match 
and an empty bucket creation instead of just jumping 
back to the start.

[...]

> I also discovered that an error status was not returned correctly
> and fixed it in the patch.
> 
> I hope it will help

Absolutely- thanks!

-- 
Joe Schaefer


Mime
View raw message