<div dir="ltr"><div>Hi,</div><div><br></div><div>I'm entertaining the idea of how useful would it be for hg server to know </div><div>a thing or two about the client that is connecting to it. More </div><div>specifically, things I think could be useful to know on the server-side</div>
<div>include:</div><div><br></div><div> * Client version</div><div> * Enabled extensions</div><div> * Platform</div><div> * ...and something else</div><div><br></div><div>How I see this implemented is either by including all this information in</div>
<div>a User-Agent string or in some kind of X-HG-CLIENT header or combination</div><div>thereof:</div><div><br></div><div> GET <a href="http://host?cmd=capabilities">http://host?cmd=capabilities</a> HTTP/1.1</div><div> Accept-Encoding: identity   </div>
<div> Accept: application/mercurial-0.1</div><div> User-Agent: mercurial/proto-2.8.2</div><div> X-Hg-Client: extensions=largefiles,projrc,convert,page,rebase,mq;</div><div>   platform=windows;</div><div><br></div><div>I don't know what are the implications of bumping version number in</div>
<div>"User-Agent: mercurial/proto-1.0", probably somebody can chime in</div><div>and destroy this whole idea.</div><div><br></div><div>How can this be useful, you ask? For one, this would allow server to</div><div>
enforce a client to enable specific extensions (like projrc, which is</div><div>useful in a corporate environment) or warn about outdated version or</div><div>possible problems with repository on a local machine (when cloning a</div>
<div>repository created on a case-sensitive file system to a Windows machine).</div><div><br></div><div>This might introduce slight security problems with exposing a list of</div><div>enabled extensions to the server, but this can be solved with a client-</div>
<div>side configuration knob, which would default to existing, "anonymous"</div><div>behavior.</div><div><br></div><div>What do you think of that?</div><div><br></div><div>Thanks,</div><div>Anton.</div></div>