- 15 Feb, 2015 6 commits
-
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
- 14 Feb, 2015 2 commits
-
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
Previously if HTTP/1 proxy is used for backend connection, we read all incoming bytes from proxy including response body, which may be part of HTTP/2 protocol. While investigating this issue, we found that http_parser_execute() returns 1-less length when we call http_parser_pause() inside on_headers_complete callback. To workaround this, we increment the return value by 1. This commit also fixes possible segmentation fault error, which could be caused by the lack of stopping libev watcher in disconnect().
-
- 13 Feb, 2015 2 commits
-
-
Tatsuhiro Tsujikawa authored
Previously we did not handle the situation where RST_STREAM is submitted against a stream while requet HEADERS which opens that stream is still in queue. Due to max concurrent streams limit, RST_STREAM is sent first, and then request HEADERS, which effectively voids RST_STREAM. In this commit, we checks RST_STREAM against currently pending request HEADERS in queue and if stream ID matches, we mark that HEADERS as canceled and RST_STREAM is not sent in this case. The library will call on_frame_not_sent_callback for the canceled HEADERS with error code from RST_STREAM.
-
Tatsuhiro Tsujikawa authored
-
- 12 Feb, 2015 9 commits
-
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
- 11 Feb, 2015 5 commits
-
-
Tatsuhiro Tsujikawa authored
Previously we use 16K - 9 bytes (frame header) as frame payload size so that whole frame fits in 1 TLS record size (16K). But it turns out that in proxy use case, we will receive 16K payload from backend and we have to split it into 2 odd looking frames (16K - 9 and 9), and latter is highly inefficient. To avoid this situation, we decided to use min frame payload size to 16K. Since we operates on TLS as stream of data, we are not so much restricted in its record size.
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
We missed wb.reset(), which makes write buffer's capacity becomes 0 and communication stalls eventually.
-
- 10 Feb, 2015 7 commits
-
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
- 09 Feb, 2015 7 commits
-
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
Previously we treat stream in NGHTTP2_STREAM_RESERVED state specially, that is we don't increment or decrement streams counts if stream is in that state. Because of this, we don't change the stream state to NGHTTP2_STREAM_CLOSING if stream is in NGHTTP2_STREAM_RESERVED. But it turns out that it causes a problem. If client canceled pushed stream before push response HEADERS, stream is still in NGHTTP2_STREAM_RESERVED state. If push response HEADERS arrived in this state, library happily accepts it and passed to application. With this commit, this bug was corrected. We now change stream state to NGHTTP2_STREAM_CLOSING even if it was in NGHTTP2_STREAM_RESERVED state. We now use NGHTTP2_STREAM_FLAG_PUSH to determine whether we have to increase/decrase stream count.
-
- 08 Feb, 2015 2 commits
-
-
Tatsuhiro Tsujikawa authored
-
Tatsuhiro Tsujikawa authored
-