Date: Fri, 26 May 2000 09:45:40 +1000 From: Joe Shevland <shevlandj@kpi.com.au> To: Bob K <melange@yip.org> Cc: Steve Roome <steve@sse0691.bri.hp.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Transparent proxies and fetch Message-ID: <392DBB24.97A3C084@kpi.com.au> References: <Pine.BSF.4.21.0005251018160.26314-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the responses and advice. I also had a newsgroup poster send in the fact that you can: <quote from mikko> Try "make FETCH_BEFORE_ARGS=-tb", or add "FETCH_BEFORE_ARGS=-tb" to /etc/make.conf. I don't have a 3.x machine to test with, but that should do it. </quote> which I believe will work as the -b option usually works when I try that. Mikko reported it is because fetch closes down its sending end before receiving the reply and the above causes it to hold it open. Regards, Joe Bob K wrote: > > On Thu, 25 May 2000, Steve Roome wrote: > > > Then again, someone might have a better solution, but IMHO I think > > it's quite rude of ISP's to divert your traffic without letting you > > know about it, imagine how you'd feel if they started diverting all > > your outgoing port23 connections and archiving everything that went > > down that line. > > > > Others may feel differently about it though! And it's becoming far too > > standard a practice now, so maybe we're supposed to move with the > > times and accept it? I dunno! > > Well, I work for an ISP that does exactly this (automatic proxy/cache of > http), and the reason we do it is because it saves thousands of dollars a > month by cutting our inbound traffic roughly in half. > > A workaround if the ISP is unwilling to exclude your IP from the > redirection (like, if you're on dialup with a dynamic IP, for example) > would be to to use a SOCKS server that's not on your ISP's network. > > *** > Another workaround would be to try to grab the files manually through ftp > (or saved through a web browser) and stick 'em in /usr/ports/distfiles/ . > *** > > However, I know for a fact that fetch (at least on 3.4R) has no problems > with Cacheflow 3040 boxes deployed. I suspect that the problem looks like > this: > > - fetch sends out the http:// request > - the ISP's gateway redirects it to a caching box > - the caching box makes the request to the server > - for some reason, there's a delay > - a timer expires in fetch, causing the "Document contains no > data" error. I would expect that it would return a different error if the > timer was expiring on the caching box (as the box would return an error as > opposed to nothing) or on the server you were trying to fetch from (for > the same reason). > > fetch appears to have a timeout switch, ie -T [seconds]. Perhaps you > could try inserting very high timeout values into the Makefiles? > > -- > Bob <melange@yip.org> > "Reality is the only word in the language that should always be used > in quotes" - The Amityville Horror III > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message -- Joe Shevland Principal Consultant KPI Logistics Pty Ltd http://www.kpi.com.au mailto:shevlandj@kpi.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?392DBB24.97A3C084>