You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2007/04/23 08:13:37 UTC
DO NOT REPLY [Bug 42190] New: - Similar to bugid #35424, this seems to occur on Apache2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42190>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42190
Summary: Similar to bugid #35424, this seems to occur on Apache2
Product: Apache httpd-2
Version: 2.2.4
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Core
AssignedTo: bugs@httpd.apache.org
ReportedBy: jrm.apache@darktide.net
When running a long-running CGI under Apache2, the connection is closed abruptly
rather than return an error code:
Connection trace:
O> GET /cgi-bin/test.cgi HTTP/1.0
O>
Connection closed by foreign host.
The simple CGI was:
#!/bin/sh
/bin/date +"`hostname -s`[$$]: I was called at %D %T" >> /tmp/test.log
echo "Content-Type: text/plain"
echo ""
sleep 1000
Setting the 'Timeout' value in Apache down to 5 seconds or so makes this bug
easier to debug (rather than the quite high default).
Under Apache1.3 we see the behavior:
O> GET /cgi-bin/test.cgi HTTP/1.0
O>
I> HTTP/1.1 200 OK
I> Date: Mon, 23 Apr 2007 06:10:26 GMT
I> Server: Apache
I> Connection: close
I> Content-Type: text/plain
Connection closed by foreign host.
I suspect that this is similar to the bug 35424 which relates to the same
behaviour occurring under Apache 1.3. I will note am surprised that Apache13
returns a '200' reply rather than a timeout, but that's a minor nitpick compared
to 224 closing the connection.
If you require any further debug output let me know.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 42190] - Similar to bugid #35424, this seems to occur on Apache2
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42190>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42190
nick@webthing.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
------- Additional Comments From nick@webthing.com 2007-04-23 02:54 -------
How is this a bug?
Or in other words, how would you expect the server to behave when a script times
out or crashes, having already sent the headers?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 42190] - Similar to bugid #35424, this seems to occur on Apache2
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42190>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42190
------- Additional Comments From slive@apache.org 2007-04-24 08:41 -------
Nick's point is that apache sends the headers right away, including the status
code. Otherwise it would need to queue up the entire response just to make sure
that no error occurs along the way. This would obviously be unacceptable for
most situations. So once your script has already sent headers, apache has sent
the (200) status code, and there is no way to later go back and say "that should
have been 500".
On the other hand, I think Nick missed your point that 2.x is not sending the
headers at all. I haven't confirmed your tests, but you are right that the 2.x
behavior your describe is not optimal.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 42190] - Similar to bugid #35424, this seems to occur on Apache2
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42190>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42190
jrm.apache@darktide.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
------- Additional Comments From jrm.apache@darktide.net 2007-04-23 18:33 -------
(In reply to comment #1)
> How is this a bug?
>
> Or in other words, how would you expect the server to behave when a script times
> out or crashes, having already sent the headers?
Well, Apache 1.3 behaviour was changed to return a proper HTTP reply (as per the
other mentioned BugID #35424).
I'm finding that applications I'm using - because they don't receive a proper
HTTP reply are subsequently retrying and this is causing issues. I guess the
other part that irks me is that this was handled correctly under Apache 1.3 and
now is not consistent with that sort of expected response in Apache2.x
>From the HTTP/1.1 RFC (2616), it looks as though the retry if connection closed
is a proper behavior. I just don't believe that closing the connection under a
timeout condition is the best response - Particularly given that this is likely
to cause a retry.
In either case, it's my belief that the server should respond with a '504
Gateway Timeout' under both Apache 1.3 and 2.x (though oddly enough Apache1.3
returns a '200 OK' with the previous bugID mentioned - which seems flawed to me).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org