httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <...@sunstarsys.com>
Subject Re: libapreq (preliminary comments on the multipart.c code)
Date Tue, 12 Dec 2000 03:33:20 GMT
Jim Winstead <jimw@trainedmonkey.com> writes:

> On Dec 11, Joe Schaefer wrote:
> >   I just got an account with apache.org (user joes).  Have you
> > been able to get a CVS tree going for apreq at apache.org?
> 
> close. i've got doug's cvs tree, now i just have to wait for brian
> to fix the permissions on a directory and then integrate the stuff
> we've been working on.
> 
> there's also new apreq-dev and apreq-cvs mailing lists (@httpd.apache.org,
> ezmlm-managed like the mod_perl lists). i've cc'd this there so it
> appears in the ezmlm archives.

Got it- this one was mailed only to the list.

> 
> it may be worth looking at the 'ring' code from apr-util at
> http://www.apache.org/websrc/viewcvs.cgi/apr-util/include/ap_ring.h.

Thanks for the url- looks nice (and very relevant). I should
have a reference implementation for the multipart_buffer code
using list.c,h ready for testing in a day or two. (I've got
one working now, but I'm still tinkering with it a little.)

> 
> > 2) There seems to be an accounting error at the end of
> >    multipart_buffer_read.  On a terminal CRLF, it should
> >    reduce the return value by one more (--len):
> 
> good catch.
> 

There's still something that I haven't groked yet about how the 
multipart_buffer_read code works on boundary reads. As I can't come
up with a real test page that breaks it, perhaps you could set me
straight on how it handles partial boundary reads.

Say there's a textarea posted that looks like this (string form):

...blah blah.CRLF---- section 12 of this lovely document ----CRLF...
^^^^^^^^^^^^^^^^^^^
self->buffer ends here

i.e. self->buffer = ...blah blah.CRLF--\0 (strlen = 5119)

What I think happens is that multipart_buffer_read would recognize 
the (false) partial boundary in self->buffer and change this to

...blah blah.\0\0--\0
                 ^
           (self->buf_begin)

Subsequently, I believe the ultimate string would become

...blah blah.---- section 12 of this lovely document ----CRLF...
            ^^
           CRLF dropped

As I said, I can't produce this behavior with a real example, so
I'm probably missing something.  I guess I'm just skeptical
that partial boundary matches actually work right in exceptional
cases like this.

-- 
Joe Schaefer

Mime
View raw message