From owner-freebsd-stable Thu May 25 16:38:55 2000 Delivered-To: freebsd-stable@freebsd.org Received: from www.kpi.com.au (www.kpi.com.au [203.39.132.210]) by hub.freebsd.org (Postfix) with ESMTP id 5B87537B631 for ; Thu, 25 May 2000 16:38:48 -0700 (PDT) (envelope-from shevlandj@kpi.com.au) Received: from kpi.com.au (ws06.kpi.com.au [203.39.132.219]) by www.kpi.com.au (8.9.3/8.9.3) with ESMTP id JAA31012; Fri, 26 May 2000 09:37:16 +1000 (EST) (envelope-from shevlandj@kpi.com.au) Message-ID: <392DBB24.97A3C084@kpi.com.au> Date: Fri, 26 May 2000 09:45:40 +1000 From: Joe Shevland Organization: KPI Logistics Pty Ltd X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob K Cc: Steve Roome , freebsd-stable@FreeBSD.ORG Subject: Re: Transparent proxies and fetch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for the responses and advice. I also had a newsgroup poster send in the fact that you can: 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. 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 > "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