> -----Ursprüngliche Nachricht-----
> Von: Jeff Trawick
> Gesendet: Dienstag, 18. Dezember 2007 17:43
> An: dev@httpd.apache.org
> Betreff: Re: proxy returning apr_status_t to handler?
>
>
> On Dec 17, 2007 11:20 AM, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> > On Dec 17, 2007 10:27 AM, Nick Kew <[EMAIL PROTECTED]> wrote:
> > > On Mon, 17 Dec 2007 10:22:02 -0500
> > > "Eric Covener" <[EMAIL PROTECTED]> 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
>
> 1f1
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>200 OK</title>
> </head><body>
> <h1>OK</h1>
> <p>The server encountered an internal error or
> misconfiguration and was unable to complete
> your request.</p>
> <p>Please contact the server administrator,
> [EMAIL PROTECTED] 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>
>
> 127.0.0.1 - - [18/Dec/2007:11:13:36 -0500] "POST /readbody.pl
> 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 127.0.0.1:8081
> (127.0.0.1) from 127.0.0.1 ()
> [Tue Dec 18 11:13:41 2007] [debug] proxy_util.c(1995): proxy: HTTP:
> has released connection for (127.0.0.1)
> [Tue Dec 18 11:13:41 2007] [error] [client 127.0.0.1] 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
> http_filters.c:721
> #1 0x080e5be5 in ap_http_header_filter (f=0x9125048, b=0x91256f8) at
> http_filters.c:1049
> #2 0x0808c756 in ap_pass_brigade (next=0x9125048, bb=0x91256f8) at
> util_filter.c:527
> #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
> util_filter.c:527
> #5 0x080e7374 in ap_byterange_filter (f=0x9125018, bb=0x91256f8) at
> byterange_filter.c:169
> #6 0x0808c756 in ap_pass_brigade (next=0x9125018, bb=0x91256f8) at
> util_filter.c:527
> #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
Argh. Without further testing: Does the following patch fixes this:
Index: modules/proxy/proxy_util.c
===================================================================
--- modules/proxy/proxy_util.c (revision 605247)
+++ modules/proxy/proxy_util.c (working copy)
@@ -1601,7 +1601,7 @@
#endif
r = conn->r;
- if (conn->need_flush && r) {
+ if (conn->need_flush && r && (r->eos_sent || r->bytes_sent)) {
/*
* We need to ensure that buckets that may have been buffered in the
* network filters get flushed to the network. This is needed since
BTW: This should only happen with trunk, not with 2.2.x.
Regards
Rüdiger
