On Tue, Dec 21, 2010 at 11:43:42AM -0000, [email protected] wrote: > URL: http://svn.apache.org/viewvc?rev=1051468&view=rev > Log: > * Do not drop contents of incomplete lines, but safe them for the next > round of reading. > > PR: 50481 ... > --- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original) > +++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Tue Dec 21 11:43:42 2010 > @@ -756,6 +756,10 @@ static apr_status_t ssl_io_input_getline > status = ssl_io_input_read(inctx, buf + offset, &tmplen); > > if (status != APR_SUCCESS) { > + if (APR_STATUS_IS_EAGAIN(status) && (*len > 0)) { > + /* Safe the part of the line we already got */ > + char_buffer_write(&inctx->cbuf, buf, *len); > + } > return status; > } > > @@ -782,6 +786,10 @@ static apr_status_t ssl_io_input_getline > > *len = bytes; > } > + else { > + /* Safe the part of the line we already got */ > + char_buffer_write(&inctx->cbuf, buf, *len); > + }
Just saw the backport proposal... apologies if I am not understanding this correctly: The only case affected by the second chunk of this change is where the buffer is full when trying to read a line - i.e. line longer than buffer. Right? In that case the correct behaviour of the input filter is to return a partial read with APR_SUCCESS (per AP_MODE_GETLINE semantics described in util_filter.h). So the data must *not* also be buffered in that case, and the behaviour was correct before. Was that part of the patch necessary to fix to the observed problem? The first part looks fine though s/safe/save or s/safe/buffer if I may nitpick the language ;) Regards, Joe
