Re: questions -- clarifications requested

>I have a new respect for Roy's "8 dimensional table".  The requests 
>aren't so bad (which is what I was thinking about when I said I'd do 
>it), but the responses are where the dimensions pile up. I'm still 
>cranking away at it. But, as I was trying to create the synopses for 
>each of the methods, I came across the following questions (in the 
>context of HTTP 1.1); trying to be sure of the answers slowed me down some:

Yeah, responses are the problem, did I forget to mention that?
I'd be happy to put your table in our HTTP documentation area at W3C
once it is near-finished -- eventually, I'd like to set up a Hypernews
page with assorted standards info and a pre-registry.

>1. Is the DELETE method allowed to have an Entity-Header and 
>Entity-Body in the request? (I would think not.)

Not.

>2. Are the LINK and UNLINK methods allowed to have an Entity-Body in 
>the request? Or any Entity-Header field other than "Link:"? (I would 
>think not.)

Not.

>(In this message, by "allowed" I mean that clients aren't supposed to 
>send, and servers must ignore if sent.)

Righto, that's the correct interpretation.

>3. In the PUT, DELETE, LINK, and UNLINK methods, is the intent that 
>content negotiation is allowed (via the Accept* request header fields), 
>but it is for the purpose of negotiating the content of the entity that 
>describes the result, not the entity corresponding to the URI? (I would 
>think so.)

Yep.

>4. Is the Title entity-header field required in PUT and POST methods? 
>Strongly suggested? Or optional? (I'd guess it's one of these :-)

Er, optional.

>5. Is the Title entity-header field allowed in the request for DELETE, 
>UNLINK, and LINK methods? (I would think not.)

Not.

>6. Is the URI-header entity-header field allowed in the request for 
>PUT, DELETE, UNLINK, and LINK methods? (I would think not.)

It is allowed in all of them, where applicable.  For example, if I
wanted to PUT a resource that was known by several names to a 
particular location, I would place the location in Request-URI and
the names in URI-headers.

>7. Is the Expires entity-header field allowed in requests for PUT and 
>POST methods? (I.e., can the client specify when the resource is to 
>expire when they create it?) How about in DELETE, LINK and UNLINK?

Yes on the former; No on the latter.

>8. Is the Last-modified entity-header field allowed in requests for 
>PUT, POST, DELETE, LINK and UNLINK methods? I.e., can a client specify 
>the last-modified date of a resource?

Yes on PUT and POST, but it may be overridden by the server.
No on DELETE, LINK and UNLINK.

>9. Is the Expires entity-header field ever returned from POST, PUT, 
>DELETE, LINK or UNLINK methods? (These are never cached, and the 
>description implies of Expires implies it is only used for caching purposes.)

Depends on if they are cacheable responses.  I think I agree with the later
discussion on this subject.

>10. Can the PUT, DELETE, LINK, and UNLINK methods ever return 303 (See 
>Other) status code?  If so, does it mean that the method succeeded or failed?

Yes, and success is dependent on the retrieval of the "Other".

>11. Is it the intent that PUT, DELETE, LINK, and UNLINK methods ever 
>return 204 (No Content), which is supposed to mean that there is no new 
>content to show? If they don't want to return a description of the 
>result of the request, do they return Content-Length of 0, or 204? Same 
>question for POST? For POST, it seems more plausible that there might 
>be a sequence of POSTs, some of which returned 204 if the result of the 
>query had not changed.

Yes, 204, 204, and I suppose so.

Hmmmm, now I just have to figure out where the spec needs clarification
on these issues ...


 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Saturday, 2 September 1995 14:25:03 UTC