1. 13 Sep, 2014 2 commits
    • Tatsuhiro Tsujikawa's avatar
    • Tatsuhiro Tsujikawa's avatar
      Add nghttp2_option_set_recv_client_preface() · 901de5fb
      Tatsuhiro Tsujikawa authored
      By default, nghttp2 library only handles HTTP/2 frames and does not
      recognize first 24 bytes of client connection preface. This design
      choice is done due to the fact that server may want to detect the
      application protocol based on first few bytes on clear text
      communication. But for simple servers which only speak HTTP/2, it is
      easier for developers if nghttp2 library takes care of client
      connection preface.
      
      If this option is used with nonzero val, nghttp2 library checks first
      24 bytes client connection preface. If it is not a valid one,
      nghttp2_session_recv() and nghttp2_session_mem_recv() will return
      error NGHTTP2_ERR_BAD_PREFACE, which is fatal error.
      901de5fb
  2. 10 Sep, 2014 3 commits
  3. 01 Sep, 2014 1 commit
  4. 29 Aug, 2014 4 commits
  5. 28 Aug, 2014 3 commits
  6. 27 Aug, 2014 7 commits
  7. 26 Aug, 2014 2 commits
    • Tatsuhiro Tsujikawa's avatar
      python: Add version · 70a8fd59
      Tatsuhiro Tsujikawa authored
      70a8fd59
    • Tatsuhiro Tsujikawa's avatar
      nghttpx: Don't consume response data in downstream on_stream_close_callback · 223242b5
      Tatsuhiro Tsujikawa authored
      Even after on_stream_close_callback, Http2DownstreamConnection is
      still alive and upstream keeps sending response to the client.  The
      consumed bytes are processed normally (data_source_read_callback) and
      also we have a code to consume all allocated bytes for
      Http2DownstreamConnection object when it is deleted.  This means that
      we don't need to and should not consume response data in downstream
      on_stream_close_callback.  If we do, we may get assertion error in
      Http2DownstreamConnection::resume_read().
      223242b5
  8. 25 Aug, 2014 17 commits
  9. 24 Aug, 2014 1 commit
    • Scott Mitchell's avatar
      Send window size API extension · 3cd08251
      Scott Mitchell authored
      Motivation:
      
      The send window size is currently fixed by a macro at compile time.
      In order for users of the library to impact the send window size they
      would have to change a macro at compile time. The window size may be dynamic
      depending on the environment and deployment scheme. The library users
      currently have no way to change this parameter.
      
      Modifications:
      
      Add a new optional callback method which is called before data is sent to
      obtain the desired send window size. The callback return value will be
      subject to a range check for the current session, stream, and settings
      limits defined by flow control.
      
      Result:
      Library users have control over their send sizes.
      3cd08251