httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@apache.org>
Subject Re: cvs commit: httpd-2.0/server protocol.c
Date Thu, 27 Mar 2003 21:48:26 GMT
Jeff Trawick wrote:
> gregames@apache.org wrote:
> 
>> gregames    2003/03/27 12:34:56
>>
>>   Modified:    server   protocol.c
>>   Log:
>>   ap_rgetline_core: set the number of bytes read & copied into the 
>> caller's
>>   buffer when returning APR_ENOSPC.  This prevents seg faults in
>>   ap_get_mime_headers_core in an error path which handles headers that 
>> are too
>>   long.
>>     Submitted by:    Jeff Trawick
> 
> unclear; see below :)
> 
>>   @@ -390,6 +391,7 @@
>>                last_char = *s + bytes_handled - 1;
>>            }
>>            else {
>>   +            *read = n;
> 
> 
> I thought this should be
> 
>                  *read = bytes_handled;
> 
> since bytes_handled tells how many bytes were successfully copied to the 
> caller's buffer, whereas n just tells how big the callers buffer is
> (or am I confused???)

Back up to the "if" statements that correspond to these two else's. 
bytes_handled is bigger than the size of the caller's buffer in these two cases, 
unless I missed something.  It seems safer to go with the smaller of the two.

This is a garbage header anyway.  The only getline caller we know of that does 
anything in this error situation tries to be a nice guy and return some of the 
garbage header back to the client in the request body of the error message.  I 
wouldn't mine nuking that code, but I assume some Smart Person thought about it 
before commiting it way back when.

Greg


Mime
View raw message