+1 for the patch in 2.0.44.
Longer term, a better solution might be able to fix the problem
closer to its source. I'm assuming, based on the code, that the
problem only occurs when the "folding" logic in ap_get_mime_headers_core
is invoked. That's the only case I see where the the size of the
field can grow arbitrarily large. (If the field is on a single
line, its length is limited within ap_rgetline_core.) I think it
would be cleaner to impose the length limit in the folding code.
But for now, the current patch is okay.
Brian
On Tue, 2002-12-10 at 11:27, Greg Ames wrote:
> [EMAIL PROTECTED] wrote:
>
> > Modified: server protocol.c
> > Log:
> > prevent a potential seg fault in ap_escape_html if a header field is too
> > long.
>
> I'd like to move this back to the 2.0 stable branch so it could be included in
> 2.0.44. Can I get some eyeballs on it and some +1s? and is this a legit way to
> proceed with getting patches moved back to 2.0 stable?
>
> Since this is in a rarely hit error leg, I can't honestly convince myself that x
> days in 2.1 HEAD without reported problems is a valid proof of stability.
>
> Thanks,
> Greg
>
> > Revision Changes Path
> > 1.123 +2 -0 httpd-2.0/server/protocol.c
> >
> > Index: protocol.c
> > ===================================================================
> > RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
> > retrieving revision 1.122
> > retrieving revision 1.123
> > diff -u -r1.122 -r1.123
> > --- protocol.c 3 Dec 2002 08:38:45 -0000 1.122
> > +++ protocol.c 10 Dec 2002 02:56:26 -0000 1.123
> > @@ -778,6 +778,8 @@
> > || (rv == APR_SUCCESS
> > && len > (apr_size_t)r->server->limit_req_fieldsize)) {
> > r->status = HTTP_BAD_REQUEST;
> > + /* insure ap_escape_html will terminate correctly */
> > + field[r->server->limit_req_fieldsize] = '\0';
> > apr_table_setn(r->notes, "error-notes",
> > apr_pstrcat(r->pool,
> > "Size of a request header field "
>
>
>
