This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author demian.brecht
Recipients berker.peksag, brett.cannon, demian.brecht, ezio.melotti, pitrou
Date 2014-12-10.21:22:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1418246547.57.0.280552826091.issue22992@psf.upfronthosting.co.za>
In-reply-to
Content
After some further investigation, this seems to be what's happening. Note: this is based on a small amount of research and hasn't been validated by any mercurial devs, so it might be missing key pieces: In cases where a local topological head is unknown to a remote, the commit history of that head's branch is sent to the remote server for comparison. This /is/ chunked, but it seems that the number of commits sent per request is hardcoded to 200 (in Mercurial 2.9.2 at any rate). Because 200 commit hashes are added to the header, the size of the header is greater than what is allowed by the app server (I'm seeing > 8k headers when the discovery step runs with my changes) leading to the error responses when using HTTP(S). So, to encounter this issue, the following must be true:

* The user must have a topological head that the remote is unaware of
* The number of commits resulting from a DAG traversal must result in a header that exceeds the allowed limits of the given app server

Because the discovery requests are chunked, if the allowed header size was increased on the app server to account for the worst case scenario (200 commit hashes), this problem should be fixed and not encountered again as I previously thought would be the case.
History
Date User Action Args
2014-12-10 21:22:27demian.brechtsetrecipients: + demian.brecht, brett.cannon, pitrou, ezio.melotti, berker.peksag
2014-12-10 21:22:27demian.brechtsetmessageid: <1418246547.57.0.280552826091.issue22992@psf.upfronthosting.co.za>
2014-12-10 21:22:27demian.brechtlinkissue22992 messages
2014-12-10 21:22:27demian.brechtcreate