- From: Howard Melman <melman@osf.org>
- Date: Wed, 23 Aug 1995 17:26:45 -0400
- To: Roy Fielding <fielding@beach.w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed Aug 23, 1995, Roy Fielding wrote:
> Paul Leach <paulle@microsoft.com> writes:
>
> >The overall thrust of what I'd like to see: for each method, a list of
> >the request header fields that are required, optional, and defaults for
> >them, if any; a list of the possible status codes and response header
> >fields; and whether of not an entity header is present in either
> >direction and its contents if so.
>
> That would be a 5 dimensional table. Since I have yet to see a table
> format that accomplished this without duplicating every line of the
> current spec, I'd be pleasantly surprised if you could do one.
I don't think Paul necessarily meant a table.
Think man page per method:
Method: GET
Request Headers:
Authorization Optional
From Optional
If-Modified-Since Optional
Orig-URI Optional
Referer Optional
User-Agent Should
Entity Headers
Entity
Possible Status Codes
200 Success, resource included as entity in response
301 The resource has moved permanently, see Location header
302 The resource has moved temporarily, See Location header
304 ...
I approach the spec from the point of view of implementing a
server. Okay, I need to write the GET code now, what
headers can I expect in legal messages and what do I have to
return in the responses. I would think client writers would
approach it the same way. As the spec is currently layed
out, I find getting this information very difficult.
> The reason the current specification seems difficult to read
> is because it is a flattened 5 dimensional table in prose.
No wonder I've been confused :-) I think 7 man-like pages
(one per method) would go a long way to helping.
Howard
Received on Wednesday, 23 August 1995 14:28:38 UTC