<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 11:35 PM Pierre-Yves David <<a href="mailto:pierre-yves.david@ens-lyon.org">pierre-yves.david@ens-lyon.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 4/17/19 8:33 PM, Martin von Zweigbergk wrote:<br>
> <br>
> <br>
> On Wed, Apr 17, 2019 at 10:41 AM Pierre-Yves David <br>
> <<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>>> <br>
> wrote:<br>
> <br>
> <br>
> <br>
> On 4/17/19 7:17 PM, Martin von Zweigbergk wrote:<br>
> ><br>
> ><br>
> > On Wed, Apr 17, 2019 at 10:07 AM Pierre-Yves David<br>
> > <<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>>>><br>
> > wrote:<br>
> ><br>
> > # HG changeset patch<br>
> > # User Pierre-Yves David <<a href="mailto:pierre-yves.david@octobus.net" target="_blank">pierre-yves.david@octobus.net</a><br>
> <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank">pierre-yves.david@octobus.net</a>><br>
> > <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank">pierre-yves.david@octobus.net</a><br>
> <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank">pierre-yves.david@octobus.net</a>>>><br>
> > # Date 1555516590 -7200<br>
> > # Wed Apr 17 17:56:30 2019 +0200<br>
> > # Node ID 6882a0101d389e27d697bf2e9717de176f273309<br>
> > # Parent 607a0de9bae31df526da75b68ab2853787d8c31e<br>
> > # EXP-Topic discovery-speedup<br>
> > # Available At <a href="https://bitbucket.org/octobus/mercurial-devel/" rel="noreferrer" target="_blank">https://bitbucket.org/octobus/mercurial-devel/</a><br>
> > # hg pull<br>
> > <a href="https://bitbucket.org/octobus/mercurial-devel/" rel="noreferrer" target="_blank">https://bitbucket.org/octobus/mercurial-devel/</a> -r 6882a0101d38<br>
> > peer: introduce a limitedarguments attributes<br>
> ><br>
> > When set to True, it signal that the peer cannot receive too<br>
> larges<br>
> > arguments<br>
> > and that algorithm must adapt. This should only be True for http<br>
> > peer that does<br>
> > not support argument passed as "post".<br>
> ><br>
> > This will be useful to unlock better discovery performance in<br>
> the next<br>
> > changesets.<br>
> ><br>
> > I am using a dedicated argument because this is not really a<br>
> usual<br>
> > "capabilities" things. An alternative approach would be to adds a<br>
> > "large-arguments" to all peer, but the http peers. That<br>
> seemed a bit<br>
> > too hacky<br>
> > to me.<br>
> ><br>
> > diff --git a/mercurial/httppeer.py b/mercurial/httppeer.py<br>
> > --- a/mercurial/httppeer.py<br>
> > +++ b/mercurial/httppeer.py<br>
> > @@ -382,6 +382,7 @@ class httppeer(wireprotov1peer.wirepeer)<br>
> > self._path = path<br>
> > self._url = url<br>
> > self._caps = caps<br>
> > + self.limitedarguments = caps is not None and<br>
> 'httppostargs'<br>
> > not in caps<br>
> <br>
> <br>
> Should we limit them also if `caps is None`?<br>
> <br>
> ><br>
> ><br>
> > Is `'httppostargs' not in caps` enough to know that httppostargs<br>
> will be<br>
> > used for the "heads" request?<br>
> <br>
> the `httppostargs` capabilities is http specific and cannot be used<br>
> outside of the httppeer code (for example, ssh server has no argument<br>
> side issue but still won't says they are httppostargs capable).<br>
> <br>
> (note: we are talking about the `known` command heres, `heads` takes no<br>
> arguments)<br>
> <br>
> > As I said in an earlier email, I'm not<br>
> > sure it will be respected for GET requests (and "heads" is a GET<br>
> > request, right?). Did you check that this will not result in a<br>
> GET request?<br>
> <br>
> I am a bit confused about what you mean here. `known` will be included<br>
> into a batch command (or standalone for quite older server). that<br>
> command will be get of post according to `httppostargs`, won't it?<br>
> <br>
> I don't think I understood what your final question is. Can you try<br>
> again?<br>
> <br>
> <br>
> Question 1: Do "heads" and "known" request normally use GET or POST <br>
> (without this patch, without batching)?<br>
> <br>
> I believe the answer is "GET".<br>
<br>
I tried to figure out that part, but could not figure it out. If you <br>
know where to look, I would be happy to get a pointer<br>
<br>
<br>
> Question 2: Do "batch" requests use POST?<br>
> <br>
> I believe the answer is "yes".<br>
<br>
According to my code reading and test: yes.<br>
<br>
> Question 3: Does httppostargs switch GET requests to POST requests?<br>
> <br>
> I believe the answer is "no".<br>
<br>
I have no idea. If not, we should probably do it.<br>
<br>
> Together, that seems to mean that we now rely on the requests getting <br>
> batched for the httppostargs thing to take effect. Correct? If correct, <br>
> it seems we should also check if the server supports batching before we <br>
> decide to remove the limit.<br>
<br>
I think so. I am fine with that. sending a follow up<br></blockquote><div><br></div><div>Joerg already replied to this thread saying that the answer to question 3 is "yes", so I don't think we need to do anything else.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
-- <br>
Pierre-Yves David<br>
</blockquote></div></div>