Re: [Slashcode-general] issues with BorderManager

[info <in...@st...>]

I get similar behavior from BorderManager 3.0 clients except that s/he
requests pix.gif a hundred times plus multiple copies of the other images.
Only when the load starts to increase, the URL gets malformed and a 404
error is generated. We changed the slash 404 page to a simpler one, and it
now handles the load from this client a lot better now.

Are you getting the same multiple request behavior *before* the URLs get
malformed? 

BorderManager3.0 does read-ahead caching. It's sees imbedded images in the
HTML and does not wait for the browser to request them. BorderManager 3.0 or
some installations may not be smart enough to recognize that some images are
requested multiple times in the same page. I don't know. Here's an article
about BorderManager 3.0. Scroll down to "read ahead caching".

http://www.nwconnection.com/oct.98/border08/

-Carl
www.stopworldwar3.com


on 11/19/01 11:32 AM, jesse hirsh at je...@ta... wrote:

> 
> so i was tailing logs the other day and noticed some weird behaviour when
> a client that goes by the name "BorderManager" browses any of my slash
> sites. it seems that this client is part of novell groupware or something,
> and for whatever reason seems to garble the url:
> 
> tor-border.grey.net - - [19/Nov/2001:14:56:57 +0000] "GET
> //neksis.openflows.org/images/pix.gif HTTP/1.0" 404 5211 "-" "Mozilla/4.0
> (compatible; BorderManager 3.0)"
> 
> i.e. instead of requesting /images/pix.gif it goes for the full. this only
> seems to happen with BorderManager 3.0. at first i was ready to just curse
> and write off that particular client, but now i see a fair amount of
> people using it... any thoughts?
> 
> 
> 11:32am  up 25 days, 20:15, 10 users,  load average: 0.45, 0.41, 0.47
> 
> 
> _______________________________________________
> Slashcode-general mailing list
> Sla...@li...
> https://lists.sourceforge.net/lists/listinfo/slashcode-general
>