1. 21 Aug, 2016 3 commits
  2. 20 Aug, 2016 1 commit
    • Tatsuhiro Tsujikawa's avatar
      nghttpx: Don't change pushed stream's priority · 5f654609
      Tatsuhiro Tsujikawa authored
      There is a discussion in httpbis mailing list which argues that
      dependency tree is for client, and changing it in server side is not
      what client expects.
      https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0416.html
      
      Currently, we make pushed stream depend on the parent stream of
      associated stream (that is main HTML in most of the cases), so that
      associated stream and pushed stream become siblings.  In this case, we
      also observed that these resources complete each other to get its
      parent weight.  This means that the delivery of associated stream is
      delayed by pushed streams.
      
      So at this moment, it is not a good idea to change pushed stream
      priority in a way we do currently.
      5f654609
  3. 19 Aug, 2016 2 commits
  4. 18 Aug, 2016 4 commits
  5. 17 Aug, 2016 7 commits
  6. 16 Aug, 2016 5 commits
  7. 15 Aug, 2016 2 commits
  8. 11 Aug, 2016 6 commits
  9. 10 Aug, 2016 2 commits
  10. 09 Aug, 2016 3 commits
  11. 07 Aug, 2016 2 commits
    • Tatsuhiro Tsujikawa's avatar
      60cae325
    • Tatsuhiro Tsujikawa's avatar
      More strict stream state handling · 16c46114
      Tatsuhiro Tsujikawa authored
      Previously, in server side, we used closed streams to detect the error
      that the misbehaving client sends a frame on the incoming stream it
      explicitly closed.  With this commit, we make a further step, and
      detect one more error case.  Since we retain closed streams as long as
      the sum of its size and the number of opened streams are equal or less
      than max concurrent streams, we can safely say that if we get a frame
      which is sent on the stream that is not found in either closed or
      opened stream, it is already closed or has not existed.  Then we can
      send GOAWAY.
      
      The previous code shrinks closed streams when we closed another
      stream, but now it is removed.  It is enough to adjust closed streams
      when new incoming stream is created.
      
      While creating this commit, we noticed that
      NGHTTP2_INITIAL_MAX_CONCURRENT_STREAMS is defined as INT32_MAX.  But
      since SETTINGS can contain value up to UINT32_MAX, it is not enough.
      However, since the stream ID space is limited to INT32_MAX, it is high
      enough.  We could keep this value, but this time we deprecate
      NGHTTP2_INITIAL_MAX_CONCURRENT_STREAMS macro.  While it is in public
      header, the effect of deprecating it is negligible because of the
      reason we wrote above, and usually application sets much smaller value
      (say, 100) as SETTINGS_MAX_CONCURRENT_STREAMS.
      16c46114
  12. 06 Aug, 2016 2 commits
  13. 05 Aug, 2016 1 commit