httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@nueva.pvt.k12.ca.us>
Subject more byterange/PDF data - solution and patch included
Date Thu, 06 Feb 1997 07:15:34 GMT
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/


Mime
View raw message