Skip to content
Snippets Groups Projects
  • Matt Harbison's avatar
    f51c2780db3a
    test-lfs-test-server: add a testcase for `hg serve` · f51c2780db3a
    Matt Harbison authored
    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
    f51c2780db3a
    History
    test-lfs-test-server: add a testcase for `hg serve`
    Matt Harbison authored
    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