From owner-freebsd-bugs  Sat Jul 26 08:30:05 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA04020
          for bugs-outgoing; Sat, 26 Jul 1997 08:30:05 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA04013;
          Sat, 26 Jul 1997 08:30:03 -0700 (PDT)
Resent-Date: Sat, 26 Jul 1997 08:30:03 -0700 (PDT)
Resent-Message-Id: <199707261530.IAA04013@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, mi@aldan.ziplink.net
Received: from aldan.ziplink.net (aldan.ziplink.net [199.232.255.49])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA03648
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 26 Jul 1997 08:21:01 -0700 (PDT)
Received: from rtfm.ziplink.net (rtfm [199.232.255.52])
	by aldan.ziplink.net (8.8.5/8.8.5) with ESMTP id LAA15815
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 26 Jul 1997 11:18:54 -0400 (EDT)
Received: (from mi@localhost)
	by rtfm.ziplink.net (8.8.5/8.8.5) id LAA01327;
	Sat, 26 Jul 1997 11:20:25 -0400 (EDT)
Message-Id: <199707261520.LAA01327@rtfm.ziplink.net>
Date: Sat, 26 Jul 1997 11:20:25 -0400 (EDT)
From: Mikhail Teterin <mi@aldan.ziplink.net>
Reply-To: mi@aldan.ziplink.net
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: bin/4171: fetch(1): poor error handling in http mode
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4171
>Category:       bin
>Synopsis:       fetch(1): poor error handling in http mode
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 26 08:30:01 PDT 1997
>Last-Modified:
>Originator:     Mikhail Teterin
>Organization:
>Release:        FreeBSD 3.0-970618-SNAP i386
>Environment:


>Description:

	The link goes down while fetching a file over http,
	and the downtime is long enough for the web-server to
	timeout. Fetch does not notice the fact and waits
	forever (or just very long).
	
	It would be ideal, if it were able to sense the anavailability
	of the service and start regetting the file from where it stopped
	with the new connection. But, at least, it should exit with the
	error code.

>How-To-Repeat:

	fetch http://server/big/enough/file/for/you/to/have/time/to/unplug

>Fix:

	If it is just plain impossible with the current htt protocol,
	please, disregard this message.
>Audit-Trail:
>Unformatted: