pub struct Code {
pub class: u8,
pub detail: u8,
}
Expand description
CoAP Code Registries
generated from RFC7252 section 12.1
This document defines two sub-registries for the values of the Code field in the CoAP header within the “Constrained RESTful Environments (CoRE) Parameters” registry, hereafter referred to as the “CoRE Parameters” registry.
Values in the two sub-registries are eight-bit values notated as three decimal digits c.dd separated by a period between the first and the second digit; the first digit c is between 0 and 7 and denotes the code class; the second and third digits dd denote a decimal number between 00 and 31 for the detail.
All Code values are assigned by sub-registries according to the following ranges:
0.00 Indicates an Empty message (see Section 4.1).
0.01-0.31 Indicates a request. Values in this range are assigned by
the "CoAP Method Codes" sub-registry (see Section 12.1.1).
1.00-1.31 Reserved
2.00-5.31 Indicates a response. Values in this range are assigned by
the "CoAP Response Codes" sub-registry (see
Section 12.1.2).
6.00-7.31 Reserved
RFC7252 Section 12.1.1 Method Codes
## Method Codes [_generated from RFC7252 section 12.1.1_](https://datatracker.ietf.org/doc/html/rfc7252#section-12.1.1)The name of the sub-registry is “CoAP Method Codes”.
Each entry in the sub-registry must include the Method Code in the range 0.01-0.31, the name of the method, and a reference to the method’s documentation.
Initial entries in this sub-registry are as follows:
+------+--------+-----------+
| Code | Name | Reference |
+------+--------+-----------+
| 0.01 | GET | [RFC7252] |
| 0.02 | POST | [RFC7252] |
| 0.03 | PUT | [RFC7252] |
| 0.04 | DELETE | [RFC7252] |
+------+--------+-----------+
Table 5: CoAP Method Codes
All other Method Codes are Unassigned.
The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in [RFC5226].
The documentation of a Method Code should specify the semantics of a request with that code, including the following properties:
o The Response Codes the method returns in the success case.
o Whether the method is idempotent, safe, or both.
RFC7252 Section 12.1.2 Response Codes
## Response Codes [_generated from RFC7252 section 12.1.2_](https://datatracker.ietf.org/doc/html/rfc7252#section-12.1.2)The name of the sub-registry is “CoAP Response Codes”.
Each entry in the sub-registry must include the Response Code in the range 2.00-5.31, a description of the Response Code, and a reference to the Response Code’s documentation.
Initial entries in this sub-registry are as follows:
+------+------------------------------+-----------+
| Code | Description | Reference |
+------+------------------------------+-----------+
| 2.01 | Created | [RFC7252] |
| 2.02 | Deleted | [RFC7252] |
| 2.03 | Valid | [RFC7252] |
| 2.04 | Changed | [RFC7252] |
| 2.05 | Content | [RFC7252] |
| 4.00 | Bad Request | [RFC7252] |
| 4.01 | Unauthorized | [RFC7252] |
| 4.02 | Bad Option | [RFC7252] |
| 4.03 | Forbidden | [RFC7252] |
| 4.04 | Not Found | [RFC7252] |
| 4.05 | Method Not Allowed | [RFC7252] |
| 4.06 | Not Acceptable | [RFC7252] |
| 4.12 | Precondition Failed | [RFC7252] |
| 4.13 | Request Entity Too Large | [RFC7252] |
| 4.15 | Unsupported Content-Format | [RFC7252] |
| 5.00 | Internal Server Error | [RFC7252] |
| 5.01 | Not Implemented | [RFC7252] |
| 5.02 | Bad Gateway | [RFC7252] |
| 5.03 | Service Unavailable | [RFC7252] |
| 5.04 | Gateway Timeout | [RFC7252] |
| 5.05 | Proxying Not Supported | [RFC7252] |
+------+------------------------------+-----------+
Table 6: CoAP Response Codes
The Response Codes 3.00-3.31 are Reserved for future use. All other Response Codes are Unassigned.
The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in [RFC5226].
The documentation of a Response Code should specify the semantics of a response with that code, including the following properties:
o The methods the Response Code applies to.
o Whether payload is required, optional, or not allowed.
o The semantics of the payload. For example, the payload of a 2.05 (Content) response is a representation of the target resource; the payload in an error response is a human-readable diagnostic payload.
o The format of the payload. For example, the format in a 2.05 (Content) response is indicated by the Content-Format Option; the format of the payload in an error response is always Net-Unicode text.
o Whether the response is cacheable according to the freshness model.
o Whether the response is validatable according to the validation model.
o Whether the response causes a cache to mark responses stored for the request URI as not fresh.
Examples
use toad_msg::Code;
assert_eq!(Code { class: 2,
detail: 5 }.to_string(),
"2.05".to_string());
Fields§
§class: u8
The “class” of message codes identify it as a request or response, and provides the class of response status:
class | meaning |
---|---|
0 | Message is a request |
2 | Message is a success response |
4 | Message is a client error response |
5 | Message is a server error response |
detail: u8
2-digit integer (range [0, 32)
) that provides granular information about the response status.
Will always be 0
for requests.
Implementations§
source§impl Code
impl Code
sourcepub const fn new(class: u8, detail: u8) -> Self
pub const fn new(class: u8, detail: u8) -> Self
Create a new Code
use toad_msg::Code;
let content = Code::new(2, 05);
sourcepub fn to_human(&self) -> [char; 4]
pub fn to_human(&self) -> [char; 4]
Get the human string representation of a message code
Returns
A char
array
This is to avoid unnecessary heap allocation,
you can create a String
with FromIterator::<String>::from_iter
,
or if the alloc
feature of toad
is enabled there is a ToString
implementation provided for Code.
use toad_msg::Code;
let code = Code { class: 2,
detail: 5 };
let chars = code.to_human();
let string = String::from_iter(chars);
assert_eq!(string, "2.05".to_string());
sourcepub fn kind(&self) -> CodeKind
pub fn kind(&self) -> CodeKind
Get whether this code is for a request, response, or empty message
use toad_msg::{Code, CodeKind};
let empty: Code = Code::new(0, 0);
assert_eq!(empty.kind(), CodeKind::Empty);
let req = Code::new(0, 1); // GET
assert_eq!(req.kind(), CodeKind::Request);
let resp = Code::new(2, 5); // OK CONTENT
assert_eq!(resp.kind(), CodeKind::Response);
sourcepub const EMPTY: Self = _
pub const EMPTY: Self = _
Messages and Endpoints
generated from RFC7252 section 4.1
A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode.
There are different types of messages. The type of a message is specified by the Type field of the CoAP Header.
Separate from the message type, a message may carry a request, a response, or be Empty. This is signaled by the Request/Response Code field in the CoAP Header and is relevant to the request/response model. Possible values for the field are maintained in the CoAP Code Registries (Section 12.1).
An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error.
sourcepub const GET: Self = _
pub const GET: Self = _
GET
generated from RFC7252 section 5.8.1
The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. If the request includes an Accept Option, that indicates the preferred content-format of a response. If the request includes an ETag Option, the GET method requests that ETag be validated and that the representation be transferred only if validation failed. Upon success, a 2.05 (Content) or 2.03 (Valid) Response Code SHOULD be present in the response.
The GET method is safe and idempotent.
sourcepub const POST: Self = _
pub const POST: Self = _
POST
generated from RFC7252 section 5.8.2
The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method is determined by the origin server and dependent on the target resource. It usually results in a new resource being created or the target resource being updated.
If a resource has been created on the server, the response returned by the server SHOULD have a 2.01 (Created) Response Code and SHOULD include the URI of the new resource in a sequence of one or more Location-Path and/or Location-Query Options (Section 5.10.7). If the POST succeeds but does not result in a new resource being created on the server, the response SHOULD have a 2.04 (Changed) Response Code. If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) Response Code. POST is neither safe nor idempotent.
sourcepub const PUT: Self = _
pub const PUT: Self = _
PUT
generated from RFC7252 section 5.8.3
The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. The representation format is specified by the media type and content coding given in the Content-Format Option, if provided.
If a resource exists at the request URI, the enclosed representation SHOULD be considered a modified version of that resource, and a 2.04 (Changed) Response Code SHOULD be returned. If no resource exists, then the server MAY create a new resource with that URI, resulting in a 2.01 (Created) Response Code. If the resource could not be created or modified, then an appropriate error Response Code SHOULD be sent.
Further restrictions to a PUT can be made by including the If-Match (see Section 5.10.8.1) or If-None-Match (see Section 5.10.8.2) options in the request.
PUT is not safe but is idempotent.
sourcepub const DELETE: Self = _
pub const DELETE: Self = _
DELETE
generated from RFC7252 section 5.8.4
The DELETE method requests that the resource identified by the request URI be deleted. A 2.02 (Deleted) Response Code SHOULD be used on success or in case the resource did not exist before the request.
DELETE is not safe but is idempotent.
Trait Implementations§
source§impl Ord for Code
impl Ord for Code
source§impl PartialEq<Code> for Code
impl PartialEq<Code> for Code
source§impl PartialOrd<Code> for Code
impl PartialOrd<Code> for Code
1.0.0 · source§fn le(&self, other: &Rhs) -> bool
fn le(&self, other: &Rhs) -> bool
self
and other
) and is used by the <=
operator. Read more