1. 29 Aug, 2019 1 commit
    • Carlos Garcia Campos's avatar
      WebSockets: only poll IO stream when needed · 35f1bac5
      Carlos Garcia Campos authored
      Instead of having two pollable sources constantly running, always try to
      read/write without blocking and start polling if the operation returns
      G_IO_ERROR_WOULD_BLOCK. This patch also fixes test
      /websocket/direct/close-after-close that was passing but not actually
      testing what we wanted, because the client close was never sent. When
      the mutex is released, the frame has been queued, but not sent.
      35f1bac5
  2. 23 Aug, 2019 1 commit
  3. 31 Jul, 2019 1 commit
    • Carlos Garcia Campos's avatar
      WebSockets: add support for permessage-deflate extension · 13cea0fd
      Carlos Garcia Campos authored
      Add new API to add WebSocket extensions to SoupSession and SoupServer
      and include an implementation of permessage-deflate extension (see RFC
      7692). In the client side, supported extensions are added to the session
      as sub-features of a new session feature, SoupWebsocketExtensionManager.
      In the client side, supported extensions are added/removed directly using
      the new SoupServer API. All functions to negotiate the handshake
      (client_prepare, client_verify, server_check and server_process) have
      now a _with_extensions alternative to handle the extensions.
      13cea0fd
  4. 22 Jul, 2019 1 commit
    • Carlos Garcia Campos's avatar
      WebSockets: allow to send close frames with no body · e590c906
      Carlos Garcia Campos authored
      Using the code SOUP_WEBSOCKET_CLOSE_NO_STATUS. The spec says that code
      should not be included in a frame, but that doesn't mean we can't use it
      on the API level to mean no status. We were using 0 internally which is
      not a valid code either. When an empty close frame is received we still
      reply with a SOUP_WEBSOCKET_CLOSE_NORMAL code frame, but we return
      SOUP_WEBSOCKET_CLOSE_NO_STATUS from
      soup_websocket_connection_get_close_code() because that's actually what
      we received.
      e590c906
  5. 19 Jul, 2019 1 commit
    • Carlos Garcia Campos's avatar
      WebSockets: ignore any messages after close has been sent and received · d9c729aa
      Carlos Garcia Campos authored
      We currently ignore data frames when close has been received, but we
      should also ignore any frame after close has been sent and received.
      Currently, if we receive two close frames we end up with the code and
      reason of the second frame, while the RFC says: "The WebSocket
      Connection Close Code is defined as the status code contained in the
      first Close control frame received by the application implementing
      this protocol."
      d9c729aa
  6. 12 Jul, 2019 1 commit
  7. 04 Jul, 2019 2 commits
  8. 27 Jun, 2019 1 commit
    • Carlos Garcia Campos's avatar
      WebSockets: allow null characters in text messages data · 109bb2f6
      Carlos Garcia Campos authored
      RFC 6455 says that text messages should contains valid UTF-8, and null
      characters valid according to RFC 3629. However, we are using
      g_utf8_validate(), which considers null characters as errors, to
      validate WebSockets text messages. This patch adds an internal
      utf8_validate() function based on g_utf8_validate() but allowing null
      characters and just returning a gboolean since we are always ignoring
      the end parameter in case of errors.
      soup_websocket_connection_send_text() assumes the given text is null
      terminated, so we need a new public function to allow sending text
      messages containing null characters. This patch adds
      soup_websocket_connection_send_message() that receives a
      SoupWebsocketDataType and GBytes, which is consistent with
      SoupWebsocketConnection::message signal.
      109bb2f6
  9. 25 Jun, 2019 1 commit
    • Carlos Garcia Campos's avatar
      WebSockets: closed signal not emitted when io stream is SoupIOStream · fd794a95
      Carlos Garcia Campos authored
      That's the case of connections created by SoupSession. In that case, if
      the server hasn't closed its end of the connection, we fail to shutdown
      the client end, because shutdown_wr_io_stream() does nothing when the io
      stream is not a GSocketConnection. So, for SoupIOStream we need to get
      the base io stream which is a GSocketConnection.
      fd794a95
  10. 19 Jun, 2019 2 commits
  11. 18 Jun, 2019 1 commit
  12. 19 Mar, 2018 1 commit
  13. 01 Feb, 2018 2 commits
  14. 24 Jan, 2018 1 commit
  15. 23 Jan, 2018 1 commit
  16. 10 Jan, 2018 5 commits
  17. 07 Aug, 2017 3 commits
  18. 17 Jul, 2017 1 commit
  19. 07 Dec, 2016 1 commit
  20. 03 Dec, 2016 2 commits
  21. 03 Nov, 2016 1 commit
  22. 18 Oct, 2016 1 commit
  23. 22 Aug, 2016 1 commit
  24. 16 Jul, 2015 1 commit
  25. 03 Mar, 2015 2 commits
  26. 01 Mar, 2015 1 commit