From: sameer <sameer@c2.net>
Message-Id: <199702061937.LAA10161@gabber.c2.net>
Subject: Re: more byterange/PDF data - solution and patch included
To: new-httpd@hyperreal.com
Date: Thu, 6 Feb 1997 11:37:28 -0800 (PST)
In-Reply-To: 
 <Pine.HPP.3.95.970205224656.11383A-100000@ace.nueva.pvt.k12.ca.us> from
 Alexei Kosut at "Feb 5, 97 11:15:34 pm"
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

	I know some of their security guys, who will hopefully get us
in touch with the guys in charge of this stuff. I'll forward your
email along to one of them with a brief executive summary.

> Okay... I think I've got it now. Note that this is a long email that
> is basically a lot of explanatory drivel and then a solution and patch
> at the end. If you don't want to read it all, skip to the last three
> paragraphs and the patch, please.
> 
> For one thing, I guess using www.netscape.com was a bad idea. The
> version of their server running there is apparently different from
> every other Netscape Server in the world - it sends back multipart 206
> responses as multipart/mixed. However, every other Netscape Server of
> version 2.0 or later that I've found - including at least one
> Enterprise/2.0a, which is the same version that claims to run at
> www.netscape.com - uses multipart/x-byteranges.
> 
> This is at least understandable, through the MIME standards. It's also
> what Adobe's CGI scripts and such produce. If I change Apache to send
> multipart/x-byteranges instead of multipart/byteranges, it works. All
> the other byteserver code then works fine. So it's not *as* bad as I'd
> feared.
> 
> Unfortunately, it's still a major problem. The problem is that the
> HTTP/1.1 spec defines multipart/byteranges. In order to respond
> properly to a Range: request, we have to return multipart/byteranges,
> not multipart/x-byteranges, since that's not a legal HTTP/1.1
> response. Unfortunately, Netscape Navigator doesn't like it. 
> Now, if Netscape send "Range: x-bytes=...", life would be happy. But
> it doesn't, it sends "Range: bytes=...". Which is the same syntax as
> HTTP/1.1. So we're stuck.
> 
> Now, it turns out there's a workaround, that I'm somewhat okay with: A
> year or so ago, there was a lot of debate about how the range syntax
> was to be. Originally, it was an addition to the URL (anyone remember
> Netscape 2.0b1 and all those bad URLs it kept sending?), but it soon
> got changed to a request header. When this decision was made,
> Netscape's Ari Luotonen and John Franks at Adobe revised their
> byte-range internet draft to use this scheme, with the header
> Request-Range.
> 
> This document was mostly incorprorated as-was into HTTP/1.1. However,
> the header was changed in name to Range:. However, Netscape (at least,
> 3.01) still sends both Range: and Request-Range headers - with the same
> value. I could justify coding the server to believe that the
> Request-Range header "took precedence" over Range, and that the
> definition of Request-Range would be the same as Range, but would use
> multipart/x-byteranges, instead of multipart/byteranges.
> 
> This way, we work with HTTP/1.1 (which would never send
> Request-Range), we work with Netscape, and we don't require config
> file changing, or User-Agent checking (which always managaes to foul
> up the Mozilla clones like MSIE that actually work fine). In other
> words, everyone's happy. Except for me, of course, because I've just
> wasted four hours on something Netscape could have fixed in five
> seconds if they'd been paying attention.
> 
> A possible patch is attached at the bottom of this email.
> 
> The long-term solution is to get Netscape to fix it. Does anyone have
> some sort of casual relationship with any of the Navigator engineers,
> and could email them personally? I've never seen Netscape take their
> technical bug reports seriously (yet whenver I've suggested a cosmetic
> feature through their bug-report form, it somehow appears in the next
> release *sigh*), so the personal touch may be what's required. If no
> one has connections there, I suppose I could try random emailing of
> people listed in the about box...
> 
> Here's the patch, anyway. For inclusion in 1.2b7, of course:
> 
> Index: http_protocol.c
> ===================================================================
> RCS file: /export/home/cvs/apache/src/http_protocol.c,v
> retrieving revision 1.97
> diff -c -r1.97 http_protocol.c
> *** http_protocol.c	1997/01/30 03:46:13	1.97
> --- http_protocol.c	1997/02/06 07:11:03
> ***************
> *** 113,118 ****
> --- 113,124 ----
>       char ts[MAX_STRING_LEN], *match;
>       long range_start, range_end;
>   
> +     /* Also check Request-Range, for backwards-compatibility with second-draft
> +      * Luotonen/Franks byte-ranges (e.g. Netscape Navigator 2-3)
> +      */
> + 
> +     if (!range) range = table_get (r->headers_in, "Request-Range");
> + 
>       /* Reasons we won't do ranges... */
>   
>       if (!r->clength || r->assbackwards) return 0;
> ***************
> *** 1032,1039 ****
>   	bputs("Transfer-Encoding: chunked\015\012", fd);
>   
>       if (r->byterange > 1)
> !         bvputs(fd, "Content-Type: multipart/byteranges; boundary=\"",
> ! 	       r->boundary, "\"\015\012", NULL);
>       else if (r->content_type)
>           bvputs(fd, "Content-Type: ", 
>   		 nuke_mime_parms (r->pool, r->content_type), "\015\012", NULL);
> --- 1038,1047 ----
>   	bputs("Transfer-Encoding: chunked\015\012", fd);
>   
>       if (r->byterange > 1)
> !         bvputs(fd, "Content-Type: multipart/",
> ! 	       table_get(r->headers_in, "Request-Range") ?
> ! 	       "x-byteranges" : "byteranges",
> ! 	       "; boundary=\"", r->boundary, "\"\015\012", NULL);
>       else if (r->content_type)
>           bvputs(fd, "Content-Type: ", 
>   		 nuke_mime_parms (r->pool, r->content_type), "\015\012", NULL);
> 
> 
> -- 
> ________________________________________________________________________
> Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
> URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/
> 


-- 
Sameer Parekh					Voice:   510-986-8770
President					FAX:     510-986-8777
C2Net
http://www.c2.net/				sameer@c2.net