httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <>
Subject Re: proxy returning apr_status_t to handler?
Date Tue, 18 Dec 2007 16:43:25 GMT
On Dec 17, 2007 11:20 AM, Jeff Trawick <> wrote:
> On Dec 17, 2007 10:27 AM, Nick Kew <> wrote:
> > On Mon, 17 Dec 2007 10:22:02 -0500
> > "Eric Covener" <> wrote:
> >
> > > Thanks; Any particular concerns about the generic fix for 2.0.x?
> > >
> > Haven't looked, but if it applies cleanly, then +1 on doing so.
> same here

That generic change may just be a temporary diversion when it comes to
proxy...  Here's an alarming response for a testcase where client
didn't send enough bytes to satisfy C-L and we timed out:

HTTP/1.1 200 OK
Date: Tue, 18 Dec 2007 16:13:36 GMT
Server: Apache/2.3.0-dev (Unix) DAV/2
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain

<title>200 OK</title>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator, and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html> - - [18/Dec/2007:11:13:36 -0500] "POST / HTTP/1.1" 500 497

[Tue Dec 18 11:13:41 2007] [error] (70007)The timeout specified has
expired: proxy: prefetch request body failed to
( from ()
[Tue Dec 18 11:13:41 2007] [debug] proxy_util.c(1995): proxy: HTTP:
has released connection for (
[Tue Dec 18 11:13:41 2007] [error] [client] Handler for
proxy-server returned invalid result code 70007

backtrace for where r->status_line gets set to "200 OK":

Hardware watchpoint 2: r->status_line

Old value = 0x0
New value = 0x81493b4 "200 OK"
basic_http_header_check (r=0x9124228, protocol=0xb74c8d30) at http_filters.c:721
721 if (r->proto_num > HTTP_VERSION(1,0)
(gdb) where
#0 basic_http_header_check (r=0x9124228, protocol=0xb74c8d30) at
#1 0x080e5be5 in ap_http_header_filter (f=0x9125048, b=0x91256f8) at
#2 0x0808c756 in ap_pass_brigade (next=0x9125048, bb=0x91256f8) at
#3 0x08071f43 in ap_content_length_filter (f=0x9125030, b=0x91256f8)
at protocol.c:1337
#4 0x0808c756 in ap_pass_brigade (next=0x9125030, bb=0x91256f8) at
#5 0x080e7374 in ap_byterange_filter (f=0x9125018, bb=0x91256f8) at
#6 0x0808c756 in ap_pass_brigade (next=0x9125018, bb=0x91256f8) at
#7 0x0808c980 in ap_fflush (f=0x9125018, bb=0x91256f8) at util_filter.c:602
#8 0x080c9e62 in connection_cleanup (theconn=0x9082900) at proxy_util.c:1636
#9 0x080caad6 in ap_proxy_release_connection (proxy_function=0x8146e2d
"HTTP", conn=0x9082900, s=0x9080910) at proxy_util.c:1998
#10 0x080d5b11 in ap_proxy_http_cleanup (scheme=0x8146e2d "HTTP",
r=0x9124228, backend=0x9082900) at mod_proxy_http.c:1742
#11 0x080d5f9d in proxy_http_handler (r=0x9124228, worker=0x90bf6a8,
conf=0x90bf568, url=0x91209e8 "/cgi-bin/", proxyname=0x0,
at mod_proxy_http.c:1872
#12 0x080c67c5 in proxy_run_scheme_handler (r=0x9124228,
worker=0x90bf6a8, conf=0x90bf568, url=0x91253f6
"", proxyhost=0x0,
proxyport=0) at mod_proxy.c:2313
#13 0x080c3306 in proxy_handler (r=0x9124228) at mod_proxy.c:945
#14 0x0807fdc3 in ap_run_handler (r=0x9124228) at config.c:163
#15 0x0808050d in ap_invoke_handler (r=0x9124228) at config.c:378
#16 0x080e28f7 in ap_process_async_request (r=0x9124228) at http_request.c:244
#17 0x080e2a18 in ap_process_request (r=0x9124228) at http_request.c:288
#18 0x080df30d in ap_process_http_connection (c=0x91203d0) at http_core.c:208
#19 0x080883e7 in ap_run_process_connection (c=0x91203d0) at connection.c:43
#20 0x080887fb in ap_process_connection (c=0x91203d0, csd=0x9120220)
at connection.c:178
#21 0x0811f6e2 in process_socket (p=0x91201e0, sock=0x9120220,
my_child_num=0, my_thread_num=0, bucket_alloc=0x91221e8) at
#22 0x08120018 in worker_thread (thd=0x9109328, dummy=0x910b0e0) at worker.c:893

The only thing in the brigade being passed is a flush bucket.

View raw message