A possible bug with get_line in v1.3

[Lee Carmichael <le...@yahoo.com>]

Hello Everyone,

I have run into an odd bug with a client and multipart
file uploads. I have been running into an issue with
file uploads where a client would only have a subset
of the total files found in a post. It seems that
client would send data at a very slow rate and that
the 'find_boundary' code never located the next file's
boundary  (this could fail after the first, second, or
n file). After looking through the code, it seems that
the 'get_line' function only tries to get data into
the buffer twice before moving on. In my problem case,
these two reads could sometimes only add a single byte
or two to the buffer which would never be the next
complete boundary and/or end of line. At this point,
the get_line function would return null and the
find_boundary function would exit.

I have a patch for fix this by retrying a few more
times. Basically, it checks to see if the buffer still
has space and if there bytes remaining to be read from
the client. If so then it would try to fill the buffer
until if found a line. After a number of tries it
would give up and exit the loop. 

I am wondering if anyone else has seen this problem.
Also, would it be best for me to post the updated
'get_line' function to the list for review or is there
a better way?


Thanks for you time,

Lee


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: A possible bug with get_line in v1.3

[Lee Carmichael <le...@yahoo.com>]

> > Also, would it be best for me to post the updated
> > 'get_line' function to the list for review or is
> there
> > a better way?
> 
> Sure, let's see it.  However apreq-1 really needs a
> new release
> manager to volunteer, because my personal focus now
> is on apreq-2.

Well I've tried one thing which is:
char* get_line([...]) {
[...]
   if (!ptr) {
      int tries = 0;
      int maxtries = 15; /* some number... */

      while (self->bytes_in_buffer < self->bufsize &&
             self->r->remaining > 0 &&
             tries <= maxtries ) {
             fill_buffer(self);
             ptr = next_line(self);
             if (ptr) 
                 break;
              tries++;
       }
    }

My other thought was that if the fill_buffer function
could be smarter about its reading. It could try some
number of times to read when its buffer was not full
and there were still data available. Much like the
update to get_line above. Neither is a great choice
since both require a manual try count just in case the
content length was off. 

Thoughts?

Thanks,

Lee


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: A possible bug with get_line in v1.3

[Joe Schaefer <jo...@sunstarsys.com>]

Lee Carmichael <le...@yahoo.com> writes:

[...]

> I am wondering if anyone else has seen this problem.

Yes.

> Also, would it be best for me to post the updated
> 'get_line' function to the list for review or is there
> a better way?

Sure, let's see it.  However apreq-1 really needs a new release
manager to volunteer, because my personal focus now is on apreq-2.

-- 
Joe Schaefer