This project is mirrored from Updated .
  1. 19 Dec, 2018 1 commit
  2. 06 Dec, 2018 4 commits
  3. 05 Dec, 2018 5 commits
    • chrysn's avatar
      (silence particular flake8 message) · 3c922999
      chrysn authored
    • chrysn's avatar
      Cleanup of internals of options · 30ae1f4b
      chrysn authored
    • chrysn's avatar
      options encoding: Don't return self in decode · 521297eb
      chrysn authored
      That only happened in a very particular type of option (UInt) and was
      used in a test -- but not described in the interface and inconsistent
      with everything else.
    • chrysn's avatar
      options: minor readability cleanup · b6dc9012
      chrysn authored
      * use int.{to,from}_bytes rather than structs as those are more easily
        understood than struct items
      * avoid needless local variables
      * visual grouping
      * fix a test that fed in a string rather than bytes
    • chrysn's avatar
      options: Don't carry length around · 69bac620
      chrysn authored
      Options used to have a length property.
      Given that Python is far from embedded, and that every time an option's
      length is queried, it's encoded right after, and the issue of [130],
      that practice is abandoned and replaced with querying the encoded
      option's length.
      A test that covered the encoding lengths of integers was removed, as
      that can't be meaningfully executed any more -- the length of the
      options is already tested for where their values are compared to
      hand-encoded reference values.
  4. 17 Nov, 2018 1 commit
  5. 02 Nov, 2018 2 commits
  6. 28 Oct, 2018 1 commit
  7. 27 Oct, 2018 4 commits
    • chrysn's avatar
      Change handling of remotes · 17d1de5a
      chrysn authored
      This chane series has the larger goal of making the request URI visible
      on the server as well; in the course of that, some relics of message
      remote handling are cleaned up.
      User visible changes:
      * All messages now have remotes from the beginning
      * The requested_* attributes and unresolved_remote were replaced by the
        remote being set to UndecidedRemote; however, the old attributes are
        still usable.
      * get_request_uri() is now usable on the server side as well, provided a
        keyword argument to indicated that is passed in.
      * get_request_uri() does not report the requested host name in responses
        any more if the host name was not sent along in the request. (It may
        still do that in the simple transports.)
    • chrysn's avatar
      OSCORE: Implement new remote properties · a1741054
      chrysn authored
      .scheme was missed, and the server (by virtue of not being a transport
      (yet)) had not assigned remotes to request messages, tripping up the
      full request URI construction recently introduced into resources.
    • chrysn's avatar
    • chrysn's avatar
  8. 26 Oct, 2018 1 commit
  9. 25 Oct, 2018 8 commits
    • chrysn's avatar
      message: Store remote infos in .remote even for unresolved ones · e9e1afba
      chrysn authored
      The unresolved remote information, previously stored in _remote_hints
      and before in unresolved_remote and requested_scheme, is now stored in
      an EndpointAddress object UndecidedRemote.
      As an intended side effect, it is now no longer sufficient to set
      uri_host and no uri, reflecting the new reality of there not being a
      single CoAP protocol any more, but multiple schemes to choose from.
      Access is still available over the old accessors, and a
      unresolved_remote can still be set with the effect of setting the
      scheme to 'coap'. Applications that relied purely on sending uri_host
      may face breakage, though, and are suggested to set a full URI or set
      unresolved_remote in addition. (That path is kept as recommended one as
      that can be smoothly deprecated later, while mechanisms looking into the
      uri_host during the dispatch decision would have a harder time raising
    • chrysn's avatar
      message.get_request_uri(): Don't report host name if not transmitted · 0b09c211
      chrysn authored
      The expected behavior of get_request_uri() was previously to report the
      configured host's name in a response even if that host name was not
      transmitted. That behavior was questionable as the server could not
      certainly know the name (or more precisely: know whether it was accessed
      by IP literal or its name, even if unique), which would result in server
      and client disagreeing on the server's name even without reverse proxies
      The expected behavior is now to only express the host name if it was
      actually transmitted, otherwise to display the default (typically
      This not only gives more agreed-on results, but also helps in
      applications where an initial request is processed by some mechanism
      (eg. URI discovery): That mechanism does not need an explicit setting
      for whether or not to send the Uri-Host, because if the host is not set
      in the first step, URIs built from get_request_uri() will already have a
      literal in there.
      News-Section: Breaking changes
    • chrysn's avatar
      OSCORE: don't use get_request_uri to protect · 958b3a25
      chrysn authored
      That function does a lot of things and a lot of things with string
      manipulation; using the bare options instead was long intended, reduces
      the number of code paths possibly used in message protection, and makes
      it less prone to changes that result from fixes to get_request_uri
    • chrysn's avatar
      udp6: Fix wrong parameter to get_extra_info · 2e37f9eb
      chrysn authored
      and add comment to what else could go wrong here
    • chrysn's avatar
      addresses: Add a scheme property to the remotes · ef687199
      chrysn authored
      This is static for most, but will provide a field for indication of how
      to process a message when _remote_hints moves into a dedicated undecided
      remote class.
    • chrysn's avatar
      Proxy: Don't set Uri-Host and Uri-Port · 2f5c6bab
      chrysn authored
      This was already changed in regular requests (which used to set
      Uri-Port), and would break when somehow setting the remote becomes a
    • chrysn's avatar
      OSCORE: Fix remote recognition · a6e15f8e
      chrysn authored
      The changed code could never have worked, and things still happened to
    • chrysn's avatar
  10. 24 Oct, 2018 6 commits
  11. 23 Oct, 2018 3 commits
    • chrysn's avatar
      message: Overhaul storage of request information · 2711f8bc
      chrysn authored
      The previous content of requested_* and unresolved_remote was a cesspool
      of historically developed attributes -- stemming from the wish to
      transport the request's details into the response, but ending up being
      used for scheme selection as well.
      This update splits the information there into what was roughly
      .unresolved_remote (currently in ._remote_hints, possibly moving into
      .remote), and a single .request attribute that plainly indicates the
      full request message that was used to create the reponse.
      The old properties are still available as accessors, but due for
    • chrysn's avatar
      tests: Remove URI reconstruction · 2df29990
      chrysn authored
      The test relied on a way of tweaking the response's internals to check
      for something actually different (the behavior of multicast responses).
      As the internals change, the behavior becomes untestable in this
      workaround, and the test, at the same time, meaningless.
    • chrysn's avatar
      message: Don't set Uri-Port by default · 102a6c5d
      chrysn authored
      URI parsing used to explicitly set an Uri-Port when a non-standard port
      was used, even though when sent to that port, it becomes the default
      value of this option.
      This update only expects the changed behavior in tests, as the actual
      change in behavior is implicit in the upcoming unresolved_remote
      changes, but not very visible there.
      This does change network observed behavior, but should not break any
      applications, for if (and I doubt it) Uri-Port is ever parsed by a
      non-proxy server, in any application where a non-default value is meant
      to be used, one would need to set it explicitly using .opt.uri_port
  12. 12 Oct, 2018 4 commits