Seems to be working now. IE7 seems to honor disconnection although it
falls back to http/1.0 sometimes (not always)
xxx.250.122.18 - - [31/Aug/2007:13:23:34 +0300] "GET
/pilt/pildid/200919avatar_4344.gif HTTP/1.1" 408 223
"http://www.domain.com/index.php?showtopic=31006&st=100";
xxx.250.122.18 - - [31/Aug/2007:13:23:34 +0300] "GET
/pilt/pildid/200919avatar_4344.gif HTTP/1.0" 304 -
"http://www.domain.com/index.php?showtopic=31006&st=100";
Added patch that will produce warning message in non-debug mode with
vhost in question so it would be possible to track these kind of actions
and do some conclusions.
[Fri Aug 31 13:23:34 2007] [warn] invalid virtualhost for this child!
(www.domain.com)
I also checked mpm-itk and it does the same thing: just closes connection.
Wierd thing was that if we "return DECLINED" then it still continues
(?!) and serves request. If some return code is returned it works ok
(although this return message never gets delivered since we closed the
connection first).
Also error rate is quite rare. 5 hours testing, 5 keepalive "breakages"
and 140 000 reqs.
Janno
Janno Sannik wrote:
Matthias Vill wrote:
Hi there,
We are returning 408 HTTP_REQUEST_TIMEOUT if anybody tries such a
request. Don't know if it's right thing to do?
Or we could also just close the connection. I don't know how browsers
react, since haven't found any "smart" ones.
What happens on a 408, doesn't the user get an error page?
According to our best friend RFC 2616 for HTTP/1.1
10.4.9 408 Request Timeout
The client did not produce a request within the time that the server
was prepared to wait. The client MAY repeat the request without
modifications at any later time.
So if the client has implemented 408 it is just perfect for our
situation as we don't get like "You 've been redirected"-messages or so
but can plainly tell the browser to retry.
Most propably there won't be any POST-requests, but many browsers do
complain on redirected POST-forms.
Unfortunately , it didn't work. Internet explorer 6.0 got error and did
not reload. Now testing with "connection close" method. This seems to be
quite rare and not so straightforwardly reproduceable, since given same
conditions I couldn't make it to the error page.
Greetings
Matthias
------------------------------------------------------------------------
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
--- httpd-2.2.3-clean/server/mpm/experimental/peruser/peruser.c 2007-08-30
12:39:40.000000000 +0300
+++ httpd-2.2.3/server/mpm/experimental/peruser/peruser.c 2007-08-31
10:06:51.219040316 +0300
@@ -2741,6 +2741,14 @@
case CHILD_TYPE_PROCESSOR:
case CHILD_TYPE_WORKER:
{
+ if (sconf->senv != CHILD_INFO_TABLE[my_child_num].senv) {
+ ap_log_error(APLOG_MARK, APLOG_WARNING,
+ 0, ap_server_conf,
+ "invalid virtualhost for this child! (%s)",
r->hostname);
+ ap_lingering_close(r->connection);
+ return HTTP_REQUEST_TIME_OUT;
+ }
+
_DBG("%s %d",
child_type_string(CHILD_INFO_TABLE[my_child_num].type), my_child_num);
_DBG("request for %s / (server %s) seems to be for us",
r->hostname, r->server->server_hostname);
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
