RE: Implementing HTTP PUT

Hi Jose!

Thank you very much for your detailed information regarding PUT. I, and I'm sure
Aaron too, are most appreciative. It sounds like you are speaking as someone who
has more than a bit of experience in this area.

I do have some questions, however. (You figured that, right? :)

> -----Original Message-----
> From: www-talk-request@w3.org [mailto:www-talk-request@w3.org]On Behalf
> Of Jose Kahan
> Sent: Thursday, March 29, 2001 3:21 AM
> To: Fish
> Cc: www-talk@w3.org
> Subject: Re: Implementing HTTP PUT

<snip>

> Missing in your example is the Content-Length and Content-Type. This
> tells the server what kind of resource you're trying to create and its
> length.

Oops. Missed that. You're absolutely right. The request should obviously include
a Content-Length and Type. Good catch.

The proper response in such a case should be "411 Length Required" or "400 Bad
Request", correct?

<snip to...>

> However, for a 204,
> the spec precises that the headers can return information related
> to the resource that was just created, such as it's Etag and Location.

Okay....

> However, it doesn't say anything bout whether it's possible to send a body
> or not in the response.

Sure it does. :)

> So, Jigsaw does send a small body and
> the Content-Length and Content-Type describe that body.

Which is wrong IMO.

> For the 204, the spec does say no body should be returned.

Right! So if Jigsaw is indeed returning a body with its 204 response then it's
broke and needs to be fixed. :)

> Jigsaw seems
> to use in this case the Content-Length and Type of the resource that
> was saved. As there's no body, why not do it? The spec doesn't say if it's
> ok or not, but it should be clearer, IMO.

Hmmm. So what you're saying then is that because a 204 response MUST NOT include
an entity body, that the Content-Length and Content-Type headers included in a
204 response actually describe the entity that was just created/updated by the
preceding PUT request (i.e. the so-called "metainformation" mentioned in section
10.2.5). Is that correct?

---------------------
10.2.5 204 No Content

   The server has fulfilled the request but does not need to return an
   entity-body, and might want to return updated metainformation. The
   response MAY include new or updated metainformation in the form of
   entity-headers, which if present SHOULD be associated with the
   requested variant.
   [...]
---------------------

In other words, what you're saying is, the 204 No Content response actually
means: "even though this response may contain headers that make it appear as if
the response contains a body (such as the response one receives from a HEAD
request), the fact that this is a 204 response means there actually isn't any
body and the headers included in this response that normally apply to entity
bodies actually applies to the entity that was just PUT."

Is that correct? The 204 response means there is no body, PERIOD, so whatever
Content-Length and/or Content-Type headers you may see in such a response
actually refer to the entity just processed by the previous PUT request,
correct?

Ok. I'll buy that. And I agree that the specs are not entirely clear on this
issue. It alludes to it in the first paragraph of section 10.2.5 that I just
quoted from above, but it doesn't actually state it in precise terms.

Now what's interesting IMO is that this particular interpretation would seem to
imply, then, that the size of then entity actually created/modified could
theoretically differ from the size of the entity supplied in the PUT request. I
mean, if one issues a PUT request for an entity of 100 bytes, one would normally
expect that the resulting entity size would be 100 bytes, thus rendering the
need to return a Content-Length header in the response moot (since the entity is
question should obviously be 100 bytes, just as was requested in the PUT
request).

However, (there's always a "however", isn't there? <g>), I suppose if the
Content-Type was changed as a result of processing the PUT request, then the
Content-Length would obviously change too. Is this the reason for returning
Content-Length and Content-Type headers in a 204 response do you think? To allow
for that possibility? (e.g. sending an uncompressed entity in the PUT request
and having the server store it in compressed format for example).

<snip to...>

> I'm enclosing a complete transaction log here after. My comments on what's
> happening are prefixed with a @@. My trimming is shown with ... Hope
> it helps you.
>
> You can find more info about the lost update problems and the use
> of conditional requests in the following W3C note:
>
> =========================
> Editing the Web
> Detecting the Lost Update Problem Using Unreserved Checkout
> W3C Note May 10 1999
> http://www.w3.org/1999/04/Editing/
> ============================
>
> -jose

Excellent, Jose! That's exactly what Aaron was asking for. Thanks!

<snip trace log to...>

> @@ Server creates the resource and returns its etag. The Content-Type
> @@ and Content-Lenght relate to the body of the resource
>
> HTTP/1.1 201 Created
> Date: Thu, 29 Mar 2001 10:50:46 GMT
> Content-Length: 31
> Content-Type: text/html
> Etag: "l5bl6r:sm508fs8"
> Server: Jigsaw/2.1.0
>
> <P>Resource succesfully created

Oops! Typo on your part, I suspect. The "Content-Length" and "Content-Type"
headers in the above response relate to the entity body supplied in *this
response* and NOT to the resource [just created]. That's because this is a "201
Created" response and not a "204 No Content" response. :)

Had it been a "204 No Content" response, then your comments would be correct.
But since it's not, I believe you're comments are wrong.

Do you concur?

<snip remainder>

All in all, you've been MOST helpful, Jose. Thank you kindly. :)

--
"Fish" (David B. Trout)
   fish@infidels.org

Received on Thursday, 29 March 2001 19:13:46 UTC