Traffic Server
  1. Traffic Server
  2. TS-841

support TLS NextProtocol negotiation

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.3
    • Component/s: HTTP, SSL
    • Labels:
      None

      Description

      In order to make it possible to write protocol handlers like SPDY, we need to negotiate NPN protocol before entering the HTTP SM.

        Issue Links

          Activity

          Hide
          Leif Hedstrom added a comment -

          Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1.

          Show
          Leif Hedstrom added a comment - Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1.
          Hide
          James Peach added a comment -

          From IRC discussion:

          6:17pm] zwoop: but, not sure it should be named TSNetAcceptTLS()
          [6:17pm] zwoop: because, TSNetAccept() implies that you (the plugin) own the port
          [6:17pm] zwoop: but, with NPN, you "share" it
          [6:17pm] jpeach: that's an interesting point
          [6:17pm] zwoop: I think we'd wants something like TSRegisterNPNHandler(contp, npn_string);
          [6:17pm] zwoop: or some such
          [6:18pm] zwoop: where contp implements the SPDY statemachine (or whatever protocol it is)
          [6:18pm] jpeach: NPN implies an implementation where the server is able to route external ports to internal named endpoints
          [6:18pm] zwoop: and, it follows the same semantics as the continuation that you would normally provide with for TSNetAccept
          ...
          [6:29pm] jpeach: so NPN needs to be in core code
          [6:29pm] jpeach: we need an internal endpoint mapper to route NPN endpoints
          [6:29pm] jpeach: we need plugin API to hook it all up

          Show
          James Peach added a comment - From IRC discussion: 6:17pm] zwoop: but, not sure it should be named TSNetAcceptTLS() [6:17pm] zwoop: because, TSNetAccept() implies that you (the plugin) own the port [6:17pm] zwoop: but, with NPN, you "share" it [6:17pm] jpeach: that's an interesting point [6:17pm] zwoop: I think we'd wants something like TSRegisterNPNHandler(contp, npn_string); [6:17pm] zwoop: or some such [6:18pm] zwoop: where contp implements the SPDY statemachine (or whatever protocol it is) [6:18pm] jpeach: NPN implies an implementation where the server is able to route external ports to internal named endpoints [6:18pm] zwoop: and, it follows the same semantics as the continuation that you would normally provide with for TSNetAccept ... [6:29pm] jpeach: so NPN needs to be in core code [6:29pm] jpeach: we need an internal endpoint mapper to route NPN endpoints [6:29pm] jpeach: we need plugin API to hook it all up
          Hide
          James Peach added a comment -

          Retitle and assign to me. I have this almost complete.

          Show
          James Peach added a comment - Retitle and assign to me. I have this almost complete.
          Hide
          James Peach added a comment -

          Attached patches.

          Show
          James Peach added a comment - Attached patches.
          Hide
          James Peach added a comment -

          235bdf1 Update CHANGES
          3a458cc Fix typo
          98b85f8 Revert SSL_METHOD declaration change
          c85a874 TS-841: support TLS NextProtocol negotiation
          b282375 TS-841: Load plugins after opening sockets
          115434b TS-841: Propagate zero-length read events through SSL
          89e24d7 TS-841: Sprinkle some const pixie dust on the SSL classes
          59bf86f TS-841: Move SSLNetAccept and SSLNetProcessor into eponymous files

          Show
          James Peach added a comment - 235bdf1 Update CHANGES 3a458cc Fix typo 98b85f8 Revert SSL_METHOD declaration change c85a874 TS-841 : support TLS NextProtocol negotiation b282375 TS-841 : Load plugins after opening sockets 115434b TS-841 : Propagate zero-length read events through SSL 89e24d7 TS-841 : Sprinkle some const pixie dust on the SSL classes 59bf86f TS-841 : Move SSLNetAccept and SSLNetProcessor into eponymous files
          Hide
          Leif Hedstrom added a comment -

          It seems when accept threads are disabled, the VC is not properly reset? It used to be, I'm pretty sure, that when we accept on the net thread, we use a proxy allocator for allocating the VC. I remember adding some code around that case, to assure we release the VC on the correct freelist (proy allocator without accept thread, global freelist when accept threads are enabled).

          Perhaps this somehow got reverted ? I can definitely trigger the assert after a few requests with accept threads disabled.

          Show
          Leif Hedstrom added a comment - It seems when accept threads are disabled, the VC is not properly reset? It used to be, I'm pretty sure, that when we accept on the net thread, we use a proxy allocator for allocating the VC. I remember adding some code around that case, to assure we release the VC on the correct freelist (proy allocator without accept thread, global freelist when accept threads are enabled). Perhaps this somehow got reverted ? I can definitely trigger the assert after a few requests with accept threads disabled.
          Hide
          James Peach added a comment -

          Fixed in trunk

          Show
          James Peach added a comment - Fixed in trunk

            People

            • Assignee:
              James Peach
              Reporter:
              Leif Hedstrom
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development