Re: [STATUS] 1.3b4-dev Sat Nov 22 18:26:26 EST 1997

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

>Not sure if I captured everything... sifting through
>loads of Email

Nope, you are still missing my votes.

>    * Martin's [PATCH] add |APLOG_NOERRNO to proxy log messages
>	<19...@deejai.mch.sni.de>
>	Status: Martin +1, Dean +1

+1

>    * Marc's [PATCH] fix strtoul
>	<Pi...@alive.znep.com>
>	Status: Marc +1, Jim +1, Martin +1, Dean +1

This was already committed

>    * Paul Eggert's [PATCH] suexec/1343: year-2000 bug in suexec log
>	<Pi...@twinlark.arctic.org>
>	Status: Martin +1, Marc +1, Dean (Wants something more common)

+1

>    * Martin's [PATCH] "Signing" server generated pages
>	<19...@deejai.mch.sni.de>
>	Status: Martin +1,

Wrong patch (I vetoed this one).  +0 to the replacement of 11/22
        <19...@deejai.mch.sni.de>

>    * Marc's [PATCH] define to allow passing of Authorization header
>	<Pi...@alive.znep.com>
>	Status: Marc +1, Dean +1 (with note), Paul +1

+1

>    * Dean's protocol/1195: Bug in Authentication header (fwd)
>	<Pi...@twinlark.arctic.org>
>	Status: Conceptual: Dean +1, Paul +1, Martin +1, Ken +1

This one isn't a patch.

>    * Martin's [PATCH] [FEATURE] Clickable Path Components in ftp dir header
>	<19...@deejai.mch.sni.de>
>	<19...@deejai.mch.sni.de>
>	Status: Martin +1, Ken +1

+1 (it is also a bug fix).

>    * 206 vs. 200 issue on Content-Length
>	See <Pi...@valis.worldgate.com>

The current behavior is correct.  A range which extends beyond the actual
length of the entity is possible in cases where a device is attempting
to limit the response size (think PDA) even when it doesn't yet know
the actual length.  At least, that was the goal.

....Roy

Re: [STATUS] 1.3b4-dev Sat Nov 22 18:26:26 EST 1997

[Marc Slemko <ma...@worldgate.com>]

On Sun, 23 Nov 1997, Alexei Kosut wrote:

> On Sun, 23 Nov 1997, Roy T. Fielding wrote:
> 
> > >    * 206 vs. 200 issue on Content-Length
> > >	See <Pi...@valis.worldgate.com>
> > 
> > The current behavior is correct.  A range which extends beyond the actual
> > length of the entity is possible in cases where a device is attempting
> > to limit the response size (think PDA) even when it doesn't yet know
> > the actual length.  At least, that was the goal.
> 
> But that's not the behavior in question. What you're talking about is
> "Range: bytes=0-16384", which sends a 206 and 16k if the entity is larger,
> and a 200 if it's smaller. Apache does that (at least, it should).
> 
> What the PR is about is "Range: bytes=0-"; which in the PR submitter's
> opinion, and mine, should send a 206, but Apache currently sends a 200.
> Note that Apache will do the same thing if one has a file of 4498 bytes in
> length, and does a "Range: bytes=0-4497". It's a matter of "<" vs. "<=".

Note that, despite my given reason for liking how it is done now and for
not liking the change, I wouldn't object to it.

It should be noted that neither way of doing things can break any client
that follows the spec and only expects what the spec guarentees. 

Also note that, either way, I would suggest there is a bug.  If you go
with Alexei's view (which seems to be better supported by the spec), the
bug is obvious.  If you agree that sending a 200 is good, then the bug is
not sending an Accept-Ranges: header for such requests.  We also don't
send an Accept-Range: for requests with invalid bytes Range headers; this
is because set_byterange only sets that in headers_out if there is no byte
range request.  I am of the opinion that this would be useful to also send
it if set_byterange returns without setting a 206 status.  This gives
information to the client that we can support a range request, we just
didn't like their request.

Re: [STATUS] 1.3b4-dev Sat Nov 22 18:26:26 EST 1997

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Sun, 23 Nov 1997, Roy T. Fielding wrote:

> >    * 206 vs. 200 issue on Content-Length
> >	See <Pi...@valis.worldgate.com>
> 
> The current behavior is correct.  A range which extends beyond the actual
> length of the entity is possible in cases where a device is attempting
> to limit the response size (think PDA) even when it doesn't yet know
> the actual length.  At least, that was the goal.

But that's not the behavior in question. What you're talking about is
"Range: bytes=0-16384", which sends a 206 and 16k if the entity is larger,
and a 200 if it's smaller. Apache does that (at least, it should).

What the PR is about is "Range: bytes=0-"; which in the PR submitter's
opinion, and mine, should send a 206, but Apache currently sends a 200.
Note that Apache will do the same thing if one has a file of 4498 bytes in
length, and does a "Range: bytes=0-4497". It's a matter of "<" vs. "<=".

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *