Re: Section 14.36 Range, and PUTs

! Larry sent me the following in private mail which I think is
! the best position for dealing with unimplemeted extensions to
! PUT; in particular, in thinking about this problem more, I don't
! see how a server should silently accept an entity with content-*
! headers it doesn't understand, without complaining.
!
! I added the following sentence to the end of the first paragraph
! of the PUT method.
!
! "The recipient of the entity MUST NOT ignore any Content-* (e.g.
! Content-Range) headers that it does not understand or implement and
! MUST return a 501 (Not Implemented) response in such cases."
!
! This leaves us an out for future extensions (you can try an extension
! reliably, and get an error from a server that doesn't implement it)
! and if it is not implemented, fall back to some (possibly less efficient)
! operation.  So I don't think we can be silent about the topic.
! It will also allow people to experiment with Content-Range in 1.1.
!
! I also added the line to Range, to clarify that Range applies to
! the entity returned by a request.  The language elsewhere restricting
! Range to GET or Conditional GET operations still stands.
!				- Jim
!
! 

To:  jg@w3.org
Subject:  Re: Section 14.36 Range, and PUTs 
From:  Larry Masinter <masinter@parc.xerox.com>
Date:  Sat, 1 Jun 1996 13:30:40 PDT

We have three choices:
> 1) Right now, the spec is silent, and it may be best to keep
> it that way.
> 2) We could put some verbiage in PUT to the effect that an error should 
> be returned if the client does not understand range puts if we wanted.
> As PUT is not implemented in most servers, I don't know how much
> of a compatibility problem we'd have with those few that do...
> 3) We can explicitly forbid the use of Content-Range with PUT operations.

The recipient of an entity must not ignore any Content-* headers that
it doesn't understand or implement; in particular, a PUT operation
must not ignore Content-Range if it doesn't understand or implement
them. (Your choice 2).

Also, as I said before, add "Range is a request header that applies to
the entity returned as the result of the request." to the description
of Range:.

Received on Sunday, 2 June 1996 13:22:11 UTC