view tests/test-encoding-func.py @ 37153:f51c2780db3a

test-lfs-test-server: add a testcase for `hg serve`

I haven't figured out yet how to make the authentication checks work for a
specific list of users, so the 'web.allow-push' list is wildcarded.  (It appears
that the client doesn't react to a 401 by sending authentication data, which may
be caused in part by not having all of the headers in httpbasicauthhandler's
http_error_auth_reqed(), compared to a run of test-http.t.  But in any case, we
should probably have a separate set of tests for various authentication
scenarios.  As it is, without the wildcard, no push access is granted.)

There are several deviations from the `lfs-test-server` case:

 - `hg serve` emits a Server header.  I think Gregory indicated that this isn't
   easily suppressed.

 - `hg serve` names the "basic" transfer handler in the Batch API response.  Not
   having to specify it was for backwards compatability, so this seems like the
   right thing to do.  (`lfs-test-server` doesn't name it, whether it was
   explicitly requested by the client or not.)

 - PUT status for a newly created file is 201, per RFC-2616 [1].  The Basic
   Transfer API [2] shows an example upload transcript with a 200 response.  It
   doesn't make much sense to re-upload a file (unless it is corrupt) in an
   example, but I wouldn't be surprised if some other implementations also
   expect 200 because of this.  But the RFC says MUST use 201 for creation.

 - The Content-Type for the file transfers is "application/octet-stream", like
   the sample transcript (though I don't see it explicitly called out in the
   text elsewhere).  Using "text/plain" seems clearly wrong.

 - `lfs-test-server` isn't removing the action property and sending back an
   error code like the spec calls out when a file is missing or corrupt.  Doing
   so on the `hg serve` side reveals a bug in our client code when handling the
   response- it indicates the remote file is missing instead of corrupt around
   line 452.

I'll probably glob over the Content-Length differences once this settles down.
Prior to the recent hgweb refactoring, the Batch API response was using chunked
encodings instead.

Back to the RFC, I have no idea if the python framework handles the "MUST NOT
ignore any Content-* (e.g. Content-Range) headers that it does not understand or
implement and MUST return a 501" for a PUT request.

[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads

from __future__ import absolute_import

import unittest

from mercurial import (
    encoding,
)

class IsasciistrTest(unittest.TestCase):
    asciistrs = [
        b'a',
        b'ab',
        b'abc',
        b'abcd',
        b'abcde',
        b'abcdefghi',
        b'abcd\0fghi',
    ]

    def testascii(self):
        for s in self.asciistrs:
            self.assertTrue(encoding.isasciistr(s))

    def testnonasciichar(self):
        for s in self.asciistrs:
            for i in range(len(s)):
                t = bytearray(s)
                t[i] |= 0x80
                self.assertFalse(encoding.isasciistr(bytes(t)))

class LocalEncodingTest(unittest.TestCase):
    def testasciifastpath(self):
        s = b'\0' * 100
        self.assertTrue(s is encoding.tolocal(s))
        self.assertTrue(s is encoding.fromlocal(s))

class Utf8bEncodingTest(unittest.TestCase):
    def testasciifastpath(self):
        s = b'\0' * 100
        self.assertTrue(s is encoding.toutf8b(s))
        self.assertTrue(s is encoding.fromutf8b(s))

if __name__ == '__main__':
    import silenttestrunner
    silenttestrunner.main(__name__)