Message(*, mtype=None, mid=None, code=None, payload=b'', token=b'', uri=None, **kwargs)¶
CoAP Message with some handling metadata
This object’s attributes provide access to the fields in a CoAP message and can be directly manipulated.
- Some attributes are additional data that do not round-trip through serialization and deserialization. They are marked as “non-roundtrippable”.
- Some attributes that need to be filled for submission of the message can be left empty by most applications, and will be taken care of by the library. Those are marked as “managed”.
The attributes are:
payload: The payload (body) of the message as bytes.
mtype: Message type (CON, ACK etc, see
numbers.types). Managed unless set by the application.
code: The code (either request or response code), see
opt: A container for the options, see
mid: The message ID. Managed by the
token: The message’s token as bytes. Managed by the
remote: The socket address of the other side, managed by the
protocol.Requestby resolving the
unresolved_remote, or the
Responderby echoing the incoming request’s. Follows the
requested_*: Managed by the
protocol.Requesta response results from, and filled with the request’s URL data. Non-roundtrippable.
requested_scheme is an exception here in that it is also set on requests to indicate which transport should be used when unresolved_remote gets resolved.
host[:port](strictly speaking; hostinfo as in a URI) formatted string. If this attribute is set, it overrides
-_port) when it comes to filling the
remotein an outgoing request.
Use this when you want to send a request with a host name that would not normally resolve to the destination address. (Typically, this is used for proxying.)
postpath: Not sure, will probably go away when resources are overhauled. Non-roundtrippable.
Options can be given as further keyword arguments at message construction time. This feature is experimental, as future message parameters could collide with options.
Create a copy of the Message. kwargs are treated like the named arguments in the constructor, and update the copy.
Create Message object from binary representation of message.
Create binary representation of message from Message object.
Generate a hashable and comparable object (currently a tuple) from the message’s code and all option values that are part of the cache key and not in the optional list of ignore_options (which is the list of option numbers that are not technically NoCacheKey but handled by the application using this method).
>>> m1 = Message(code=GET) >>> m2 = Message(code=GET) >>> m1.opt.uri_path = ('s', '1') >>> m2.opt.uri_path = ('s', '1') >>> m1.opt.size1 = 10 # the only no-cache-key option in the base spec >>> m2.opt.size1 = 20 >>> m1.get_cache_key() == m2.get_cache_key() True >>> m2.opt.etag = b'000' >>> m1.get_cache_key() == m2.get_cache_key() False >>> ignore = [OptionNumber.ETAG] >>> m1.get_cache_key(ignore) == m2.get_cache_key(ignore) True
The absolute URI this message belongs to.
For requests, this is composed from the options (falling back to the remote). For responses, this is stored by the Request object not only to preserve the request information (which could have been kept by the requesting application), but also because the Request can know about multicast responses (which would update the host component) and redirects (FIXME do they exist?).
This implements Section 6.5 of RFC7252.
set_request_uri(uri, *, set_uri_host=True)¶
Parse a given URI into the uri_* fields of the options.
The remote does not get set automatically; instead, the remote data is stored in the uri_host and uri_port options. That is because name resolution is coupled with network specifics the protocol will know better by the time the message is sent. Whatever sends the message, be it the protocol itself, a proxy wrapper or an alternative transport, will know how to handle the information correctly.
set_uri_host=Falseis passed, the host/port is stored in the
unresolved_remotemessage property instead of the uri_host option; as a result, the unresolved host name is not sent on the wire, which breaks virtual hosts but makes message sizes smaller.
This implements Section 6.4 of RFC7252.
Result that can be returned from a render method instead of a Message when due to defaults (eg. multicast link-format queries) or explicit configuration (eg. the No-Response option), no response should be sent at all. Note that per RFC7967 section 2, an ACK is still sent to a CON request.