1. 10 Sep, 2015 1 commit
  2. 08 Sep, 2015 2 commits
  3. 04 Sep, 2015 4 commits
  4. 15 Aug, 2015 1 commit
    • http: propagate the credentials callback's error code · 11bca2d2
      When we ask for credentials, the user may choose to return EUSER to
      indicate that an error has happened on its end and it wants to be given
      back control.
      
      We must therefore pass that back to the user instead of mentioning that
      it was on_headers_complete() that returned an error code. Since we can,
      we return the exact error code from the user (other than PASSTHROUGH)
      since it doesn't cost anything, though using other error codes aren't
      recommended.
      Carlos Martín Nieto committed
  5. 29 Jul, 2015 1 commit
  6. 12 Jul, 2015 1 commit
  7. 30 Jun, 2015 1 commit
  8. 29 Jun, 2015 1 commit
  9. 24 Jun, 2015 4 commits
  10. 11 May, 2015 1 commit
  11. 23 Apr, 2015 3 commits
  12. 18 Mar, 2015 1 commit
  13. 16 Mar, 2015 1 commit
  14. 03 Mar, 2015 1 commit
  15. 10 Dec, 2014 2 commits
  16. 19 Nov, 2014 1 commit
    • fetch: clear the connection data on close · 1ca61bdc
      When we fetch twice with the same remote object, we did not properly
      clear the connection flags, so we would leak state from the last
      connection.
      
      This can cause the second fetch with the same remote object to fail if
      using a HTTP URL where the server redirects to HTTPS, as the second
      fetch would see `use_ssl` set and think the initial connection wanted to
      downgrade the connection.
      Carlos Martín Nieto committed
  17. 27 Oct, 2014 1 commit
  18. 22 Sep, 2014 1 commit
  19. 16 Sep, 2014 6 commits
  20. 16 Aug, 2014 1 commit
    • http: make sure we can consume the data we request · 294c6f29
      The recv buffer (parse_buffer) and the buffer have independent sizes and
      offsets. We try to fill in parse_buffer as much as possible before
      passing it to the http parser. This is fine most of the time, but fails
      us when the buffer is almost full.
      
      In those situations, parse_buffer can have more data than we would be
      able to put into the buffer (which may be getting full if we're towards
      the end of a data sideband packet).
      
      To work around this, we check if the space we have left on our buffer is
      smaller than what could come from the network. If this happens, we make
      parse_buffer think that it has as much space left as our buffer, so it
      won't try to retrieve more data than we can deal with.
      
      As the start of the data may no longer be at the start of the buffer, we
      need to keep track of where it really starts (data_offset) and use that
      in our calculations for the real size of the data we received from the
      network.
      
      This fixes #2518.
      Carlos Martín Nieto committed
  21. 15 Aug, 2014 4 commits
  22. 13 Jun, 2014 1 commit