##// END OF EJS Templates
test-lfs-test-server: add a testcase for `hg serve`...
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

File last commit:

r37036:3e74d3cc default
r37171:f51c2780 default
Show More
__init__.py
98 lines | 3.5 KiB | text/x-python | PythonLexer
# highlight - syntax highlighting in hgweb, based on Pygments
#
# Copyright 2008, 2009 Patrick Mezard <pmezard@gmail.com> and others
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
#
# The original module was split in an interface and an implementation
# file to defer pygments loading and speedup extension setup.
"""syntax highlighting for hgweb (requires Pygments)
It depends on the Pygments syntax highlighting library:
http://pygments.org/
There are the following configuration options::
[web]
pygments_style = <style> (default: colorful)
highlightfiles = <fileset> (default: size('<5M'))
highlightonlymatchfilename = <bool> (default False)
``highlightonlymatchfilename`` will only highlight files if their type could
be identified by their filename. When this is not enabled (the default),
Pygments will try very hard to identify the file type from content and any
match (even matches with a low confidence score) will be used.
"""
from __future__ import absolute_import
from . import highlight
from mercurial.hgweb import (
webcommands,
webutil,
)
from mercurial import (
extensions,
fileset,
)
# Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' for
# extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
# be specifying the version(s) of Mercurial they are tested with, or
# leave the attribute unspecified.
testedwith = 'ships-with-hg-core'
def pygmentize(web, field, fctx, tmpl):
style = web.config('web', 'pygments_style', 'colorful')
expr = web.config('web', 'highlightfiles', "size('<5M')")
filenameonly = web.configbool('web', 'highlightonlymatchfilename', False)
ctx = fctx.changectx()
tree = fileset.parse(expr)
mctx = fileset.matchctx(ctx, subset=[fctx.path()], status=None)
if fctx.path() in fileset.getset(mctx, tree):
highlight.pygmentize(field, fctx, style, tmpl,
guessfilenameonly=filenameonly)
def filerevision_highlight(orig, web, fctx):
mt = web.res.headers['Content-Type']
# only pygmentize for mimetype containing 'html' so we both match
# 'text/html' and possibly 'application/xhtml+xml' in the future
# so that we don't have to touch the extension when the mimetype
# for a template changes; also hgweb optimizes the case that a
# raw file is sent using rawfile() and doesn't call us, so we
# can't clash with the file's content-type here in case we
# pygmentize a html file
if 'html' in mt:
pygmentize(web, 'fileline', fctx, web.tmpl)
return orig(web, fctx)
def annotate_highlight(orig, web):
mt = web.res.headers['Content-Type']
if 'html' in mt:
fctx = webutil.filectx(web.repo, web.req)
pygmentize(web, 'annotateline', fctx, web.tmpl)
return orig(web)
def generate_css(web):
pg_style = web.config('web', 'pygments_style', 'colorful')
fmter = highlight.HtmlFormatter(style=pg_style)
web.res.headers['Content-Type'] = 'text/css'
web.res.setbodybytes(''.join([
'/* pygments_style = %s */\n\n' % pg_style,
fmter.get_style_defs(''),
]))
return web.res.sendresponse()
def extsetup():
# monkeypatch in the new version
extensions.wrapfunction(webcommands, '_filerevision',
filerevision_highlight)
extensions.wrapfunction(webcommands, 'annotate', annotate_highlight)
webcommands.highlightcss = generate_css
webcommands.__all__.append('highlightcss')