On 20 November 2015 at 00:03, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: rhuij...@apache.org [mailto:rhuij...@apache.org] >> Sent: donderdag 19 november 2015 19:03 >> To: comm...@subversion.apache.org >> Subject: svn commit: r1715228 - >> /subversion/trunk/subversion/libsvn_ra_serf/util.c >> >> Author: rhuijben >> Date: Thu Nov 19 18:03:11 2015 >> New Revision: 1715228 >> >> URL: http://svn.apache.org/viewvc?rev=1715228&view=rev >> Log: >> Add a tiny bit of code to allow testing with Apache Serf's http/2 support. >> >> I committed this patch to celebrate that I got through basic_tests.py >> using the current http/2 support. >> >> * subversion/libsvn_ra_serf/util.c >> (conn_negotiate_protocol): New function. >> (conn_setup): Register usage of conn_negotiate_protocol when >> a very recent (read: trunk) serf + SVN__SERF_TEST_HTTP2 are used. > > Currently most tests pass for me over http2 when running with some minor > tweaks. I still get some aborted connections that aren't retried as cleanly > as with http 1.1. Not sure what causes these yet; but this could also be an > httpd issues. > > The only ra function that really causes problems is the implementation of the > replay > range api. This 100% expects that results will be received in the same order > in which > they are sent. This is typically the correct way in http 1.1 using serf, but > even there it > is sometimes possible to get results out of order. (Authentication can > re-queue > requests... and sometimes authorization is necessary even when earlier > requests > succeeded, depending on the auth scheme). > Can we use WINDOW_UPDATE frame to control flow of replay-revision response? In this case we can use spillbuf for buffering responses to avoid latency performance regressions. What do you think?
-- Ivan Zhakov
