lfs: explicitly add the Content-Length header when uploading blobs, for py3
This was the reason for test-lfs-test-server.t#git-server complaining about an
"invalid byte in chunk length". For some reason if this isn't explicitly added,
py3.7.1 is adding `transfer-encoding: chunked` as well as `Content-length: x`.
Wireshark flagged this as malformed. However, if this is set, it doesn't bother
with `transfer-encoding`.
Before this patch with py3:
PUT /objects/
31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
Accept-Encoding: identity
Content-length: 12
accept: application/vnd.git-lfs
content-type: application/octet-stream
host: localhost:20062
transfer-encoding: chunked
user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-
7eb7637e34bf)
Before this patch with py27:
PUT /objects/
31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
Accept-Encoding: identity
accept: application/vnd.git-lfs
content-type: application/octet-stream
content-length: 12
host: localhost:20062
user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-
7eb7637e34bf+
20190128)
With this patch and py3, the content is the same as the py27 example. RFC2616
says to ignore `Content-Length` if `Transfer-Encoding` is present, so maybe
there's nothing to do in the hg-server side (though I'm not sure which it is
using if presented both).
Maybe chunked encoding is better to do? If someone knows how to suppress the
`Content-Length`, we can try that instead.
$ hg init test
$ cd test
$ echo foo>foo
$ hg addremove
adding foo
$ hg commit -m "1"
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
checked 1 changesets with 1 changes to 1 files
$ hg clone . ../branch
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ../branch
$ hg co
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo bar>>foo
$ hg commit -m "2"
$ cd ../test
$ hg pull ../branch
pulling from ../branch
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets 30aff43faee1
1 local changesets published
(run 'hg update' to get a working copy)
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
checked 2 changesets with 2 changes to 1 files
$ hg co
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat foo
foo
bar
$ hg manifest --debug
6f4310b00b9a147241b071a60c28a650827fb03d 644 foo
update to rev 0 with a date
$ hg upd -d foo 0
abort: you can't specify a revision and a date
[255]
update to default destination (with empty revspec)
$ hg update -q null
$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
30aff43faee1 tip
$ hg update -q null
$ hg update -r ''
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
30aff43faee1 tip
$ hg update -q null
$ hg update ''
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
30aff43faee1 tip
$ cd ..
update with worker processes
#if no-windows
$ cat <<EOF > forceworker.py
> from mercurial import extensions, worker
> def nocost(orig, ui, costperop, nops, threadsafe=True):
> return worker._numworkers(ui) > 1
> def uisetup(ui):
> extensions.wrapfunction(worker, 'worthwhile', nocost)
> EOF
$ hg init worker
$ cd worker
$ cat <<EOF >> .hg/hgrc
> [extensions]
> forceworker = $TESTTMP/forceworker.py
> [worker]
> numcpus = 4
> EOF
$ for i in `"$PYTHON" $TESTDIR/seq.py 1 100`; do
> echo $i > $i
> done
$ hg ci -qAm 'add 100 files'
$ hg update null
0 files updated, 0 files merged, 100 files removed, 0 files unresolved
$ hg update -v | grep 100
getting 100
100 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..
#endif