On 20 November 2015 at 11:53, Bert Huijben <b...@qqmail.nl> wrote: > Ack. > > Not pipelining, or not sending simultaneous/parallel requests if you don’t > want to depend on the order in which they are received is the safest thing. > > And the current code can break even in http/1. Svnrdump even has special > precautions for this even though I have no idea why it would see the > problems it describes it has. (The editor drive is 100% from one http > response) > > What we could do is replace the current assertion with a request on a > completely different connection to retrieve the properties if we don’t have > them in time… as a fallback mechanism to at least continue going. This also > works for legacy servers if the first improvement is applied. > > I’m not sure if the current implementation has more problems… E.g. if > revisions can also be received out of order. > > Going to a single report –that includes the revprops- for multiple revisions > is a safe extension, that will improve in all cases: HTTP and HTTP/2 alike. > I understand that current is also unsafe, that's why I suggest go single REPORT and disable pipeling for older servers. I'll add this to my TODO list you agree that this approach makes sense.
> I will start looking in supporting priority scheduling anyway…. But that > requires more work in other parts of serf first. (I can’t use the request as > an argument while serf still thinks it can destroy and recreate requests at > a different address at will as part of the auth handling) > > Ack. -- Ivan Zhakov
