Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: No Action
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.1
    • Component/s: core
    • Labels:
      None
    • Resolution:
      Hide

      TC call 17.10.2013
      TC elect to close this issue. Spec does not define any specific return codes for other transports.

      Show
      TC call 17.10.2013 TC elect to close this issue. Spec does not define any specific return codes for other transports.

      Description

      The use of Websockets as a transport is described in WD13 Appendix A line 1711

      Ken Borgendale suggests that this might also specify the close code and reason.

      Java J2EE 1.7 and Mozilla javascript give the ability to set these but other interfaces may not., so we can only make a recommendation.

      Normal closure ( 1000) would be the default, but should we recommend using 1002 Protocol_Error if there is an MQTT Protocol error etc?
      What reason text should be sent if any?

        Attachments

          Activity

          Hide
          raphcohn Raphael Cohen (Inactive) added a comment -

          I think there's 3 possible ways we could set the closure code:-

          a) Ignore it and just use 1000 even for errors unless they specifically WebSockets-related - we're using WebSockets as a transport like TCP. Does anyone ever take any notice of TCP-like failure codes apart from 'its broken' (eg when getting EPOLL_ERR, go look up the error that was last found on the FD)?
          b) Map the connack codes to a websockets private use range (which I think you're proposing above)
          c) Something else that reflects the semantics needed for WebSockets, eg just 1000 =OK and 1001 =BAD, as the connack codes are being carried in the higher-layer (MQTT packets)

          In practice, I can imagine implementations choosing to use HTTP headers to 'log in' in, so even some of the CONNACK codes might not be encountered. So I'd go for (b), but as a MAY, simply because not all implementations will be able to set the code (including those being bridged). In practice, this means that clients can't rely on a normal closure code actually being normal closure (because a bridge might not know unless it detects a broken TCP socket session).

          For reason texts, I'd propose either:-

          a) SHOULD set it to the connack description (if using b)
          b) MAY instead of SHOULD
          c) Freeform

          I'd go for c unless we have a need to distinguish error conditions by text rather than code (which I think is unlikely).

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - I think there's 3 possible ways we could set the closure code:- a) Ignore it and just use 1000 even for errors unless they specifically WebSockets-related - we're using WebSockets as a transport like TCP. Does anyone ever take any notice of TCP-like failure codes apart from 'its broken' (eg when getting EPOLL_ERR, go look up the error that was last found on the FD)? b) Map the connack codes to a websockets private use range (which I think you're proposing above) c) Something else that reflects the semantics needed for WebSockets, eg just 1000 =OK and 1001 =BAD, as the connack codes are being carried in the higher-layer (MQTT packets) In practice, I can imagine implementations choosing to use HTTP headers to 'log in' in, so even some of the CONNACK codes might not be encountered. So I'd go for (b), but as a MAY, simply because not all implementations will be able to set the code (including those being bridged). In practice, this means that clients can't rely on a normal closure code actually being normal closure (because a bridge might not know unless it detects a broken TCP socket session). For reason texts, I'd propose either:- a) SHOULD set it to the connack description (if using b) b) MAY instead of SHOULD c) Freeform I'd go for c unless we have a need to distinguish error conditions by text rather than code (which I think is unlikely).

            People

            • Assignee:
              Unassigned
              Reporter:
              andrew_banks Andrew Banks (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: