Subject: [core] CoAP response code in case of "response payload too large" ? 4.13?

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 31 Jan 2017 15:29:08 +0000

Dear all,

the following question came up in a system design that uses CoAP. What if a client asks for a resource (e.g. using query arguments) that would get prohibitively large, such that the server can't serve it? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only pertain to the request payload size - not the response payload size. In both the HTTP and CoAP cases. So it seems unsuitable for the situation I describe above.

4.00 Bad Request seems unsuitable because the syntax / formatting of the CoAP request is fine.  5.00 seems possible if we take the perspective that it is the server's fault that it cannot produce the requested (large) response payload.

Some background discussion is also on http://stackoverflow.com/questions/15192477/http-status-code-when-single-request-asks-for-too-large-resource-or-too-many-of which suggests to use 403 / 4.03 for this case. Which seems not ideal as well because it tells the client that its authorization is insufficient which is not the case here.

Does anyone have a view on this?

best regards

Esko Dijk

________________________________
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: "Padmanabhan Ramanujam (pramanuj)" <[email-masked]>
Date: Tue, 31 Jan 2017 15:52:43 +0000

I think the right error should still be 4.03 Forbidden, as it is the client which should modify its request, with something in the payload to provide sufficient indication to the client that the response will not fit. In the particular case would usage of blockwise option solve the problem.

Regards,
paddy

From: core <[email-masked]> on behalf of "Dijk, Esko" <[email-masked]>
Date: Tuesday, 31 January 2017 at 20:59
To: "core ([email-masked])" <[email-masked]>
Subject: [core] CoAP response code in case of "response payload too large" ? 4.13?

Dear all,

the following question came up in a system design that uses CoAP. What if a client asks for a resource (e.g. using query arguments) that would get prohibitively large, such that the server can't serve it? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only pertain to the request payload size – not the response payload size. In both the HTTP and CoAP cases. So it seems unsuitable for the situation I describe above.

best regards

Esko Dijk

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 31 Jan 2017 18:22:36 +0100

Hi Esko,

good question.

I agree that 4.13 does not apply, as it is about the request payload.

If you consider management of resource consumption to be part of authorization, 4.03 is somewhat plausible, but it might set the client up on a goose chase for more permissions.

5.00 of course always is possible, as are 5.01 or 5.03.  5.03 has max-age (retry-after) semantics that maybe don’t fit very well here; it is really meant for temporary conditions.

There is little guidance in RFC 7230 (or RFC 2616) when to use 501 (which our 5.01 references); it only gets specific about using it as a response when the request method is not implemented at all.

So, no, I don’t think we have a good fit here.  Is the use case important enough that we want to invent a new status code?  Otherwise, 4.03 seems to be as good to me as 5.01.

Grüße, Carsten

> On 31 Jan 2017, at 16:29, Dijk, Esko <[email-masked]> wrote:
> 
> Dear all,
>  
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Lauri Piikivi <[email-masked]>
Date: Wed, 1 Feb 2017 06:56:38 +0000

Hi alls,

I think there is a need to define further codes. We fall back on HTTP specs, and those are basically made for user interaction with a limitless server. They are not a good match for IoT where apps communicate, often constrained apps. There is space for defining machine understandable codes, or extend headers or something so that we can actually communicate what the issue is.

I propose a bit of info gathering, I  imagine there are more similar kinds of situations where HTTP has not had the right code.

It is a bit more work, but in my opinion needed in mid-to-long term for internet of things.

BR
- Lauri

> On 31 Jan 2017, at 19:22, Carsten Bormann <[email-masked]> wrote:
>
> Hi Esko,
>
> good question.
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Feb 2017 08:21:39 +0100

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

> I propose a bit of info gathering, I  imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”.  If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine.  If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten