From marcs@valis.worldgate.com  Mon Mar  3 23:07:55 1997
Received: from valis.worldgate.com (marcs@valis.worldgate.com [198.161.84.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA01505
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 3 Mar 1997 23:07:54 -0800 (PST)
Received: (from marcs@localhost)
	by valis.worldgate.com (8.8.5/8.8.5) id AAA28947;
	Tue, 4 Mar 1997 00:07:47 -0700 (MST)
Message-Id: <199703040707.AAA28947@valis.worldgate.com>
Date: Tue, 4 Mar 1997 00:07:47 -0700 (MST)
From: marcs@znep.com
Reply-To: marcs@znep.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: fetch won't restart http transfers
X-Send-Pr-Version: 3.2

>Number:         2870
>Category:       bin
>Synopsis:       fetch -r just doesn't work for http transfers
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jmg
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar  3 23:10:01 PST 1997
>Closed-Date:    Thu Mar 6 12:02:16 PST 1997
>Last-Modified:  Thu Mar  6 12:03:25 PST 1997
>Originator:     Marc Slemko
>Release:        FreeBSD 2.2-GAMMA i386
>Organization:
>Environment:

Latest fetch, from 2.2 or -current.

>Description:

When you try to use fetch -r against a http server to resume a
transfer, it will always give an error about "unknown Content-Range
unit".  

Once I fixed that problem, it was then filling the start of the
file with null characters when it was resumed.

>How-To-Repeat:

$ fetch http://localhost/~marcs/epi-r06.pdf
^C (abort partway through the file)
$ fetch -r http://localhost/~marcs/epi-r06.pdf



>Fix:

The following fixes the problem, and I _think_ it shouldn't
cause any other problems but have not had time to look at it in 
detail.  After this patch, fetch restarts http transfers fine for
me, although it still doesn't quite do chunked encodings properly...

Index: http.c
===================================================================
RCS file: /usr/cvs/src/usr.bin/fetch/http.c,v
retrieving revision 1.4
diff -c -r1.4 http.c
*** http.c	1997/02/11 20:46:05	1.4
--- http.c	1997/03/04 06:57:47
***************
*** 857,863 ****
  	if (to_stdout)
  		local = fopen("/dev/stdout", "w");
  	else
! 		local = fopen(fs->fs_outputfile, "w");
  	if (local == 0) {
  		warn("%s: fopen", fs->fs_outputfile);
  		fclose(remote);
--- 857,863 ----
  	if (to_stdout)
  		local = fopen("/dev/stdout", "w");
  	else
! 		local = fopen(fs->fs_outputfile, "a");
  	if (local == 0) {
  		warn("%s: fopen", fs->fs_outputfile);
  		fclose(remote);
***************
*** 1263,1269 ****
  	u_quad_t first, last, total;
  	char *ep;
  
! 	if (strcasecmp(orig, "bytes") != 0) {
  		warnx("unknown Content-Range unit: `%s'", orig);
  		return EX_PROTOCOL;
  	}
--- 1263,1269 ----
  	u_quad_t first, last, total;
  	char *ep;
  
! 	if (strncasecmp(orig, "bytes", 5) != 0) {
  		warnx("unknown Content-Range unit: `%s'", orig);
  		return EX_PROTOCOL;
  	}
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->jmg 
Responsible-Changed-By: jmg 
Responsible-Changed-When: Tue Mar 4 00:24:22 PST 1997 
Responsible-Changed-Why:  
I'll take this one, I've been working on fetch recently... 

From: Garrett Wollman <wollman@lcs.mit.edu>
To: marcs@znep.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: bin/2870: fetch won't restart http transfers
Date: Tue, 4 Mar 1997 10:06:11 -0500

 <<On Tue, 4 Mar 1997 00:07:47 -0700 (MST), marcs@znep.com said:
 
 >   	if (to_stdout)
 >   		local = fopen("/dev/stdout", "w");
 >   	else
 > ! 		local = fopen(fs->fs_outputfile, "a");
 >   	if (local == 0) {
 >   		warn("%s: fopen", fs->fs_outputfile);
 >   		fclose(remote);
 
 This is incorrect.  The correct code would be:
 
 	if (to_stdout)
 		local = fopen("/dev/stdout", restarting ? "a" : "w");
 	else
 		local = fopen(fs->fs_outputfile, restarting ? "a" : "w");
 
 The comment immediately above should probably be fixed as well.
 
 
 > ! 	if (strncasecmp(orig, "bytes", 5) != 0) {
 >   		warnx("unknown Content-Range unit: `%s'", orig);
 >   		return EX_PROTOCOL;
 >   	}
 
 This patch is correct.  I don't know how I missed this.
 
 -GAWollman

From: Garrett Wollman <wollman@lcs.mit.edu>
To: Marc Slemko <marcs@znep.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/2870: fetch won't restart http transfers
Date: Tue, 4 Mar 1997 12:43:23 -0500

 <<On Tue, 4 Mar 1997 09:23:13 -0700 (MST), Marc Slemko <marcs@znep.com> said:
 
 > I actually thought about it, but:
 
 > 	1. how are we going to append to stdout and what meaning
 > 	   does that have?
 
 If standard output is connected behind-the-scenes to a file (e.g.,
 `fetch -ro - foo >>bar'), then opening it for append has meaning.
 Standard output is not always a tty or a pipe.
 
 > 	2. what does it matter if we open it for appending, since a
 > 	   file opened for appending need not exist and we seek to
 > 	   the start before writing anyway.
 
 Because by definition, writes to a file opened in append mode ALWAYS
 happen at the end of the file.  Actually, I take back my earlier
 suggestion; for restart mode to work properly, the file should be open
 in "r+" mode for both cases (since we might restart before the end if
 the file if that's what the remote server wants).
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, ANA, or NSA|                     - Susan Aglukark and Chad Irschick
State-Changed-From-To: open->closed 
State-Changed-By: jmg 
State-Changed-When: Thu Mar 6 12:02:16 PST 1997 
State-Changed-Why:  
fixed in revision 1.6 of src/usr.bin/fetch/http.c 
>Unformatted:
