httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: project plan
Date Fri, 12 Jul 1996 17:55:31 GMT
On Fri, 12 Jul 1996, Robert S. Thau wrote:

>   (not all of HTTP/1.1, just the hard parts *grin*).
> Hmmm... if I'm not mistaken, "the hard parts" of full HTTP/1.1 support
> are sending (as opposed to receiving) chunked transfer-encoding (and
> doing it without rewriting mod_ssi, mod_cgi, mod_asis, mod_dir &c)., 
> and byte-range support, and both are optional within the protocol.

Yep, those are the ones. (and they are).

> If I'm right about both these things, the right strategy might be to
> do the "easy" parts of HTTP/1.1 for an Apache-1.2 release, and save
> the full-strength stuff for 2.0.  (Then again, if byte-range support

That sounds like a good idea. As I've said, I really don't like the way I
had to implement chunking and byte-ranges in http11.patch. Having a
package like sfio around makes this suddenly a heck of a lot easier. I
think I agree with this strategy... so unless someone *really* wants me to
leave in the current hack (one that, btw, requires three complete
flushes for each chunked file sent - and we're having performance problems
with theone we call now?), I'll plan to take it out of the next rev of the

> is restricted to plain files, the implementation no longer requires
> quite so much deep voodoo...).

Yes, that's correct. And I've done some serious thinking, and I think the
next version of my HTTP/1.1 patch (sometime this weekend) will move the
byterange stuff out of buff.c and into http_protocol.c, called from
default_handler(). This means that only files handled by the core will
support byteranges (or any other module that specficially calls the
functions), but as it stands now, none of the modules call
set_content_length() (where I'm setting byterange stuff now) *anyhow*, so
that shouldn't be a big loss.

The reason is that I keep having nightmares about someone doing a repeated
request for a ten gig file with "Range: bytes=-10", and I just think of
that more hard drive grinding through ten gigs of that file (flushing out
the disk cache in the process, and slowing disk access to heck) and
tossing out all but the last ten bytes. If you ask me, a fseek() and a
read of just the ten bytes makes a lot more sense. (and it's the way, at
least, that Netscape Server 2.0 seems to do it).

-- Alexei Kosut <>            The Apache HTTP Server

View raw message