Re: Prelim. DAV spec.

At 10:47 AM 10/27/96 PST, Larry Masinter wrote:
>I think there's a design choice people are facing in trying to
>reconcile versioning and content negotiation, and I want to argue for
>one choice over another:

I have some metapoints on the draft and how it relates to HTTP that I don't
think have been raised.

It took a long time before we got the terminology right in HTTP and without
doubt this caused the final specification to be delayed for some time. The
lesson to learn from this is that not having the basics right leads to
major problems later on.

There were a couple of terminology issues that were not realized in the
HTTP work before very late in the process. They may seem to be evident but
let me recap them for a moment:

1) A resource is identified by a URL. That is, no resource exists outside
the URL name space and only resources are accessible through the Web.

2) HTTP transports entities - not resources. An HTTP method performs an
operation on the resource which in the classic case of "GET" generates a
snapshot of what the resource looks like to this particular request.

Luckily, many requests are very similar and hence the result of a method
can often be cached and reused by other clients. Note, however, that an
entity does  not have a URL and hence is not a resource! The entity tag or
the date can be used by a client to verify that the cached entry is still
valid in the sense that it still resembles the result produced by the
resource when poked with a similar request.

3) All entities in a HTTP response may be subject to content negotiation.
This includes error messages, redirections, and any other entity type.
Content negotiation is not limited to "200 OK" responses.

The server MUST use the vary header to indicate that the entity was
negotiated as a function of the request. 

The server may use the Content-Location header to indicate the exact
location of the resource corresponding to a particular entity at the time
of the request.

4) A resource does not move from the origin server. Unlike mail where the
message is moved around on the Net, a resource stays on the origin server
at all times. When a client creates a new entity, it includes an entity in
the request and asks the server to create a resource with the initial
contents being the entity.

So what does this mean to distributed authoring? I think the two main
points are:

A) Distributed authoring is about editing/creating resources - not
entities! This is in fact the root of the "editing the source" problem
which I haven't seen discussed in the draft (unless I have missed something).

If the resource is a plain HTML file, then there is no difference between
the resource and the entity included in the HTTP response - they contain
exactly the same bytes. In other words - good old file system semantics
hold true and the entity can be edited directly.

However, if the resource represents dynamic contents, a data base view, a
CGI script or a server side include then what you GET is not identical to
the resource. In this situation, file system semantics break down and the
entity can in general not be edited directly.

B) Content negotiation is not a problem. The client can always see if the
entity has been negotiated or not. If the server provided it with a
Content-Location header it can use that when issuing a PUT request (libwww
uses this) and if not then it relies on the server to pick the right
location based on the entity tag.

The immediate solution to problem A) is to have two different methods for
viewing (GET) and editing (EDIT). However, this requires you always to
explicitly contacting the server in order to edit a document. Hence,
off-line editing becomes very hard. Also, in all the "plain HTML" cases,
having different methods add extra overhead even though there is no
difference between the result of the two methods. New methods also have the
problem that they don't pass old proxies very well.

Another solution is to have the server indicating when file system
semantics do not hold true. In order to avoid a new method this can be done
by adding a "Link" header to the response indicating the location where the
client can get the resource itself and not the entity generated as a
response to a GET request.

In the case of a data base entry, this can be a HTML form for
entering/editing data, and in the case of a CGI script or server side
include (SSI), this is where the client can get the CGI program or the
unparsed SSI file.

An example:

	GET /dynamic/contents.html HTTP/1.1
	Host: CGI-server

	HTTP/1.1 200 OK
	Link: source.cgi; rel="source"
	etc.

In this examppe, the link URL is relative to the Request-URI. It can of
course also be pointing to another server as any other URL.

Thanks,

Henrik

Received on Monday, 28 October 1996 13:03:06 UTC