Subject: [core] draft-ietf-core-block-08 - Disentangle Block and Success Response Codes

From: Klaus Hartke <[email-masked]>
Date: Tue, 17 Apr 2012 04:18:25 +0200

When a client performs an atomic block-wise POST/PUT, the server
returns a 2.01 (Created) or 2.04 (Changed) response for each uploaded
block. coap-09 defines the two response codes as follows:

* 2.01 (Created) means that a resource was created at the target
URI/Location URI and requires that a cache marks any stored response
for the created resource as not fresh.
* 2.04 (Changed) means that the target resource was changed and
requires that a cache marks any stored response for the changed
resource as not fresh.

The problem is: the target resource is not really created or changed
in an atomic block-wise POST/PUT before the last block is uploaded.
Invalidating all caches long before the POST/PUT is complete doesn't
sound like a good idea.

I propose to return a different, new response code that doesn't have
an effect on caches and conveys the non-final nature of the response.
An equivalent of the HTTP 100 status code [1] would be the best fit:

- 100 Continue

      The client SHOULD continue with its request.  This
      interim response is used to inform the client that the
      initial part of the request has been received and has
      not yet been rejected by the server.  The client
      SHOULD continue by sending the remainder of the
      request or, if the request has already been completed,
      ignore this response.  The server MUST send a final
      response after the request has been completed.

Klaus

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.1.1

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 17 Apr 2012 09:06:11 +0000

Hi Klaus,

FYI I made another proposal to 'fix' this that slightly modifies the meaning of response codes in the -block context: see http://www.ietf.org/mail-archive/web/core/current/msg02372.html

(Also the earlier/related thread messages related to this one are relevant in this discussion.)

This interpretation in my view is already present in the current -block spec, although not explicitly.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Tuesday 17 April 2012 4:18
To: [email-masked]
Subject: [core] draft-ietf-core-block-08 - Disentangle Block and Success Response Codes

- 100 Continue

Klaus

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.1.1
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 09:24:02 -0600

+1 - this solution makes sense to me.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Apr 2012 18:16:27 +0200

> - 100 Continue

Now #211.

Grüße, Carsten