So far what I have discovered: IE6.0 and IE7.0 have broke it quite a few times. Seems like, if IE breaks the connection it will most likely do it many times (!) in a row. Logs show that it sometimes makes a connection, get's refused, makes another one request, get's refused and then make another request and get's page it was looking for . Maybe ie has mupltiple keepalive connections which it uses in parallel and if first get's killed off then it uses another one (which also fails). I have seen this behaviour on downloading files: if you download 2 files from same server it will not start third download until it finishes one of the downloads in progress. It applies to one server only ie it does allow more than 2 downloads if they aside on different servers. IE does not retry POST requests, at least that what's I've seen so far ( 1 ).
Firefox: Client works 100% as expected: if it gets connection closed it reconnects and gets response on second time and all is great . It also does retry if POST fails ( 1 ) . So very nice and clean without any problems. Only browsers I have seen so far are firefox (very few) and IE (6, 7). Haven't seen any other browsers so far. The thing is that it happens quite rarely. About 20 reqs out of 300 000 reqs a day and therefore is very hard to reproduce. Most incidents occur on morning times where we have a main page with email login form, which POSTs to different vhost where webmail is. This is quite a good schema for testing actually :P And about performane: it is noticeably faster :) Stefan Seufert wrote: > I've been on vacation for the last weeks, so apologies for jumping in > late. From my personal experience with the backhand project I can > confirm that browsers can safely be expected to reuse their connections > only if the host portion of the url remains constant. > > IIS 4 for example ignored the host header of subsequent requests and > always served them from the same vhost as the first request. So the > assumption that keepalive requests are always for the same vhost should > be safe, otherwise a lot of clients would have shown problems before. > > Stefan > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser > _______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
