416 implementation incompatibility V3

While working with our implementations of HTTP/1.1, we've come across
a compatibility problem with the 416 range unsatisfiable response.

Browsers implemented based on 2068 prior to the 416 behavior's introduction
don't understand the 416 response.  The previous behavior was that an 
unsatisfiable range request was ignored and a 200 response followed.

Our problem is that IE4, which supports range requests, would, in certain
cases, depend on this behavior.  In tests with 416 server implementations,
the browser receives this unexpected response which it cant handle
gracefully. (just receive the whole file again, and go on with life as
usual instead of interrupting the operation and the user with an error).

The crux is that we end up in a situation with a cached document
which is marked partial because, event though we've actually read 
as much as the content length indicates, we didn't actually "read to EOF".
On the next retrieve the browser attempts to fetch the rest of the document
with a range request which begins with the byte after the last byte
in the file.  In older implementations we just get the whole file again,
but in newer server implementations we get a 416, which is an error.

I'll avoid going into the exact details of how we get into this
situation and just say that at the time we implemented it,
this area of the spec wasn't completely clear and our behavior
is probably a bug in our implementation.

Being that IE4 has long since been shipped, we are unsure how to
proceed.  Our discussions have revisited the reasoning for why
an unsatisfiable range request should get an error while an
invalid request (syntax) would be ignored.

It seems to me that we have introduced a feature in http/1.1
which is incompatible with the initial spec for http/1.1.  In general
this is something we should avoid and makes me wonder if we should
strike the 416 from http/1.1.

Taking that one step further, I'm inclined to wonder if the right
thing may be to take 416, mandatory and options, drop them in 
a spec with the version number bumped.  This would let new
extensions or features get standardized in a separate fashion
via the extension framework.

your thoughts?

Received on Thursday, 28 May 1998 18:17:47 UTC