From owner-freebsd-current Wed Jul 23 15:42:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20280 for current-outgoing; Wed, 23 Jul 1997 15:42:34 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20274 for ; Wed, 23 Jul 1997 15:42:30 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id QAA16961; Wed, 23 Jul 1997 16:42:11 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id QAA29827; Wed, 23 Jul 1997 16:43:41 -0600 (MDT) Date: Wed, 23 Jul 1997 16:43:41 -0600 (MDT) From: Marc Slemko To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Garrett Wollman , FreeBSD-current Subject: Re: 'fetch' error with http, fix wanted In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id PAA20275 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It will happen at times if you try to talk to certain boxes with T/TCP like SunOS 4.x boxes. Disable net.inet.tcp.rfc1644 and it should work. You probably only see it with fetch because it appears to be more efficient with the way it sends the headers, so the request goes in a single packet with the SYN. Haven't looked into it further to see who is at fault yet. Oh yes, on a completely unrelated note... fetch is also broken in that it makes HTTP/1.1 requests but doesn't properly deal with the results. This gains it absolutely nothing but hurts a lot in some case. eg. fetch http://www.apache.org/index.html doesn't give the proper output because fetch doesn't know about chunked encoding. It is bogus, both in theory and practice, for fetch to claim to be HTTP/1.1 if it can't handle chunked encodings. On Thu, 24 Jul 1997, [KOI8-R] Андрей Чернов wrote: > On Wed, 23 Jul 1997, Garrett Wollman wrote: > > > < said: > > > > > This command > > > fetch http://www.lothlorien.net/~squirrel/giger/art/Necronomicon_I.jpg > > > > > always says "connection reset by peer" in the middle of file transfer, > > > meanwhile, new -current ftp or lynx do it sucessfully! > > > Does anybody knows sockets enough to fix it? > > > > I would make a wild guess and suggest that it's likely a TCP bug on > > their end, but without being able to get a tcpdump trace of it I can't > > be certain. (It could, of course, also be a TCP bug on our end.) > > > > But why ftp or lynx always works, if it is TCP bug? They show -stalled- > state sometimes and I think fetch treat -stalled- as resetting by peer... > > I see the same behaviour already 4 times in the past, but forget other > URLs. > > -- > Andrey A. Chernov > > http://www.nagual.pp.ru/~ache/ >