Re: POST questions

Tim Berners-Lee <>
Date: Mon, 4 Oct 93 17:36:42 +0100
From: Tim Berners-Lee <>
Message-id: <>
Subject: Re: POST questions


I agree that the URL should be returned as a header, and in fact  
there may be other bit sof metadata whioch would be server-generated
and would be returned at the same time.  I have changed the spec to

"Return object headers

The method shall return a set (possibly empty) of object headers for  
the newly posted object.  If a URL has been assigned by the server,  
then that may be included.  Similarly, if a URN has been assigned,  
then that shall be returned. Other things which may be returned  
include for example the expiry-date if any.   The server may return  
the entire metadata for the object (as in the HEAD command), or a  
subset of it.

The object body shall not be returned, so the transaction shall end  
with the blank line terminating the headers."

I would expect one could use the same code for implementing HEAD
to a large extent.  On getting the returned header, the client would  
sync up its internal data on the object, which is incomplete until  
the post has happened.

2. At the same time I feel like changing the Live-URL: fields
to a

URI: blah  vary=version, language, content-type

field.  I didn't get any feedback on that.  Seemed sensible though,
cleaner.  Any objections? **** Speak now...

3. The message-boundary.

> Secondly, how should "message boundary" work?  I've seen
>    Content-type: text/html, boundary="string"
> and
>    Message-Boundary: string

It is a pain that MIME defines it in the first form, and only for
Content-type multipart.  I guess we would do best to go
the same way.  Where have you seen the second method?
(I would prefer it on the encoding rather than the type field)