[EMAIL PROTECTED] 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
