As of v2.5.1, we provide an option to disable automatic detection of the
Content-Type and always use application/octet-stream instead. However,
when that option is set, instead of providing a Content-Type of
application/octet-stream, we fail to provide one at all.
Ensure that we always set some Content-Type header when uploading files
by skipping the detection but preserving the fallback behavior when the
option is set.
In [1], we used 'zip(1)' to create *.zip files in these integration
tests because ZIP files begin with the header:
[]byte{0x50, 0x4B, 0x03, 0x04}
And thus are detected as 'application/zip' by http.DetectContentType().
However, this 'zip(1)' program does not exist on Windows, hence the
recent test failures (starting as early as [1]).
Instead, let's use 'tar -czf', which creates gzip-compressed tarballs,
and begin with the header:
[]byte{0x1F, 0x8B, 0x80}
Thus are detected as 'application/x-gzip' by http.DetectContentType().
This should allow this test to run on AppVeyor (and more generally, on
Windows as a whole) again.
[1]: 938df5c4 (tq/basic_upload.go: disable Content-Type detection by
configuration, 2018-07-31)
In the commit introducing this code ([1]), I wrote a typo such that the
'git config' invocation changed did not apply 'contenttype=0' to the API
call executed by 'git push origin master'.
So, when I copied and pasted this test case from the one above, I didn't
change the '1' to a '0', because when I ran 'make -B t-content-type.sh',
the test passed.
This commit fixes the incorrect spelling in 'git config' and updates the
assertion to pass, and confirms that setting a 'contenttype' to '0'
disables content-type detection.
[1]: 938df5c4 (tq/basic_upload.go: disable Content-Type detection by
configuration, 2018-07-31)
For the majority of Git LFS's lifetime, Git LFS objects have been
uploaded via HTTP and contained the header:
Content-Type: application/octet-stream
In [1], this changed and we began attempting to guess an appropriate
Content-Type header based on the first 512 bytes of the file being
uploaded.
This breaks some hosting platforms' implementation of this API, so let's
offer a way to disable this guessing to allow users to upload objects
again on affected implementations.
[1]: a1736293 (Merge pull request #3137 from
calavera/set_upload_content_type, 2018-07-23)
