facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 15:27:13 +03:00
Code Issues Projects Releases Wiki Activity
ce0723ee16
sapling/tests/test-hgweb.t

618 lines
16 KiB
Perl
Raw Normal View History

tests: replace exit 80 with #require
2014-08-06 20:43:59 +04:00
#require serve
tests: use 'hghave serve' to guard tests that requires serve daemon management
2011-11-07 06:24:53 +04:00
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
Some tests for hgweb. Tests static files, plain files and different 404's.
$ hg init test
$ cd test
$ mkdir da
$ echo foo > da/foo
$ echo foo > foo
$ hg ci -Ambase
adding da/foo
adding foo
$ hg serve -n test -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log
$ cat hg.pid >> $DAEMON_PIDS
manifest
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ ("$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/?style=raw')
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
200 Script output follows
drwxr-xr-x da
-rw-r--r-- 4 foo
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ ("$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/da?style=raw')
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
200 Script output follows
-rw-r--r-- 4 foo
plain file
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/foo?style=raw'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
200 Script output follows
foo
should give a 404 - static file that does not exist
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'static/bogus'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
404 Not Found
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<link rel="icon" href="/static/hgicon.png" type="image/png" />
<meta name="robots" content="index, nofollow" />
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
web: Made elapsed time calculation dynamic (javascript). This allow safe caching of the pages by the browser and still display the right amount of elapsed time upon page refresh. If javascript is disabled, absolute time is displayed, leaving it readable. All the templates have been updated.
2011-04-28 19:02:39 +04:00
<script type="text/javascript" src="/static/mercurial.js"></script>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<title>test: error</title>
</head>
<body>
<div class="container">
<div class="menu">
<div class="logo">
<a href="http://mercurial.selenic.com/">
<img src="/static/hglogo.png" width=75 height=90 border=0 alt="mercurial" /></a>
</div>
<ul>
<li><a href="/shortlog">log</a></li>
<li><a href="/graph">graph</a></li>
<li><a href="/tags">tags</a></li>
hgweb: add separate page with bookmarks listing
2011-03-12 13:20:03 +03:00
<li><a href="/bookmarks">bookmarks</a></li>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<li><a href="/branches">branches</a></li>
hgweb: make paper:error consistent with template Tests fixed by Patrick Mézard <patrick@mezard.eu>
2012-07-30 13:33:27 +04:00
</ul>
<ul>
hgweb: add help link to templates missed in 333983876439
2010-10-10 02:58:48 +04:00
<li><a href="/help">help</a></li>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</ul>
</div>
<div class="main">
tests: update hgweb tests to include breadcrumbs
2013-01-09 04:16:29 +04:00
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<h3>error</h3>
<form class="search" action="/log">
<p><input name="rev" id="search1" type="text" size="30"></p>
paper: edit search hint to include new feature description
2013-09-06 13:30:57 +04:00
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</form>
<div class="description">
<p>
An error occurred while processing your request:
</p>
<p>
Not Found
</p>
</div>
</div>
</div>
web: Made elapsed time calculation dynamic (javascript). This allow safe caching of the pages by the browser and still display the right amount of elapsed time upon page refresh. If javascript is disabled, absolute time is displayed, leaving it readable. All the templates have been updated.
2011-04-28 19:02:39 +04:00
<script type="text/javascript">process_dates()</script>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</body>
</html>
[1]
should give a 404 - bad revision
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/spam/foo?style=raw'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
404 Not Found
error: revision not found: spam
[1]
should give a 400 - bad command
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/foo?cmd=spam&style=raw'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
400* (glob)
error: no such method: spam
[1]
hgweb: fail if an invalid command was supplied in url path (issue4071) Traditionally, the way to specify a command for hgweb was to use url query arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an error (e.g. "400 no such method: badcmd"). But there's also another way to specify a command: as a url path fragment (e.g. "/graph"). Before, hgweb was made forgiving (looks like it was made in cd356f4efd91) and user could put any unknown command in the url. If hgweb couldn't understand it, it would just silently fall back to the default command, which depends on the actual style (e.g. for paper it's shortlog, for monoblue it's summary). This was inconsistent and was breaking some tools that rely on http status codes (as noted in the issue4071). So this patch changes that behavior to the more consistent one, i.e. hgweb will now return "400 no such method: badcmd". So if some tool was relying on having an invalid command return http status code 200 and also have some information, then it will stop working. That is, if somebody typed foobar when they really meant shortlog (and the user was lucky enough to choose a style where the default command is shortlog too), that fact will now be revealed. Code-wise, the changed if block is only relevant when there's no "?cmd" query parameter (i.e. only when command is specified as a url path fragment), and looks like the removed else branch was there only for falling back to default command. With that removed, the rest of the code works as expected: it looks at the command, and if it's not known, raises a proper ErrorResponse exception with an appropriate message. Evidently, there were no tests that required the old behavior. But, frankly, I don't know any way to tell if anyone actually exploited such forgiving behavior in some in-house tool.
2014-09-22 18:46:38 +04:00
$ "$TESTDIR/get-with-headers.py" --headeronly localhost:$HGPORT '?cmd=spam'
400 no such method: spam
[1]
should give a 400 - bad command as a part of url path (issue4071)
$ "$TESTDIR/get-with-headers.py" --headeronly localhost:$HGPORT 'spam'
400 no such method: spam
[1]
$ "$TESTDIR/get-with-headers.py" --headeronly localhost:$HGPORT 'raw-spam'
400 no such method: spam
[1]
$ "$TESTDIR/get-with-headers.py" --headeronly localhost:$HGPORT 'spam/tip/foo'
400 no such method: spam
[1]
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
should give a 404 - file does not exist
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/bork?style=raw'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
404 Not Found
error: bork@2ef0ac749a14: not found in manifest
[1]
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/bork'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
404 Not Found
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<link rel="icon" href="/static/hgicon.png" type="image/png" />
<meta name="robots" content="index, nofollow" />
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
web: Made elapsed time calculation dynamic (javascript). This allow safe caching of the pages by the browser and still display the right amount of elapsed time upon page refresh. If javascript is disabled, absolute time is displayed, leaving it readable. All the templates have been updated.
2011-04-28 19:02:39 +04:00
<script type="text/javascript" src="/static/mercurial.js"></script>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<title>test: error</title>
</head>
<body>
<div class="container">
<div class="menu">
<div class="logo">
<a href="http://mercurial.selenic.com/">
<img src="/static/hglogo.png" width=75 height=90 border=0 alt="mercurial" /></a>
</div>
<ul>
<li><a href="/shortlog">log</a></li>
<li><a href="/graph">graph</a></li>
<li><a href="/tags">tags</a></li>
hgweb: add separate page with bookmarks listing
2011-03-12 13:20:03 +03:00
<li><a href="/bookmarks">bookmarks</a></li>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<li><a href="/branches">branches</a></li>
hgweb: make paper:error consistent with template Tests fixed by Patrick Mézard <patrick@mezard.eu>
2012-07-30 13:33:27 +04:00
</ul>
<ul>
hgweb: add help link to templates missed in 333983876439
2010-10-10 02:58:48 +04:00
<li><a href="/help">help</a></li>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</ul>
</div>
<div class="main">
tests: update hgweb tests to include breadcrumbs
2013-01-09 04:16:29 +04:00
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<h3>error</h3>
<form class="search" action="/log">
<p><input name="rev" id="search1" type="text" size="30"></p>
paper: edit search hint to include new feature description
2013-09-06 13:30:57 +04:00
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</form>
<div class="description">
<p>
An error occurred while processing your request:
</p>
<p>
bork@2ef0ac749a14: not found in manifest
</p>
</div>
</div>
</div>
web: Made elapsed time calculation dynamic (javascript). This allow safe caching of the pages by the browser and still display the right amount of elapsed time upon page refresh. If javascript is disabled, absolute time is displayed, leaving it readable. All the templates have been updated.
2011-04-28 19:02:39 +04:00
<script type="text/javascript">process_dates()</script>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</body>
</html>
[1]
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'diff/tip/bork?style=raw'
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
404 Not Found
error: bork@2ef0ac749a14: not found in manifest
[1]
try bad style
tests: prepare get-with-headers.py for MSYS get-with-headers.py took the http GET parameter as a command line parameter that had to start with '/'. MSYS on windows will mangle such paths. Instead of applying a workaround everywhere (such as an extra '/') we let get-with-headers.py add the mandatory '/'. That is consistent with the url path handling in the Mercurial url class. A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET /?cmd=...'. This will not enable any tests for being run on windows - only remove one reason they were disabled.
2012-06-21 05:05:02 +04:00
$ ("$TESTDIR/get-with-headers.py" localhost:$HGPORT 'file/tip/?style=foobar')
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
200 Script output follows
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<link rel="icon" href="/static/hgicon.png" type="image/png" />
<meta name="robots" content="index, nofollow" />
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
web: Made elapsed time calculation dynamic (javascript). This allow safe caching of the pages by the browser and still display the right amount of elapsed time upon page refresh. If javascript is disabled, absolute time is displayed, leaving it readable. All the templates have been updated.
2011-04-28 19:02:39 +04:00
<script type="text/javascript" src="/static/mercurial.js"></script>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<title>test: 2ef0ac749a14 /</title>
</head>
<body>
<div class="container">
<div class="menu">
<div class="logo">
<a href="http://mercurial.selenic.com/">
<img src="/static/hglogo.png" alt="mercurial" /></a>
</div>
<ul>
<li><a href="/shortlog/2ef0ac749a14">log</a></li>
<li><a href="/graph/2ef0ac749a14">graph</a></li>
<li><a href="/tags">tags</a></li>
hgweb: add separate page with bookmarks listing
2011-03-12 13:20:03 +03:00
<li><a href="/bookmarks">bookmarks</a></li>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<li><a href="/branches">branches</a></li>
</ul>
<ul>
<li><a href="/rev/2ef0ac749a14">changeset</a></li>
<li class="active">browse</li>
</ul>
<ul>
web: add a help view for getting hg help output
2010-10-09 21:27:14 +04:00
</ul>
<ul>
<li><a href="/help">help</a></li>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</ul>
</div>
<div class="main">
tests: update hgweb tests to include breadcrumbs
2013-01-09 04:16:29 +04:00
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<h3>directory / @ 0:2ef0ac749a14 <span class="tag">tip</span> </h3>
<form class="search" action="/log">
<p><input name="rev" id="search1" type="text" size="30" /></p>
paper: edit search hint to include new feature description
2013-09-06 13:30:57 +04:00
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</form>
<table class="bigtable">
hgweb: replace implicit <tbody> with explicit <thead> where appropriate Some templates in paper style use <tbody> elements inside <table> to assign a class to "body" part of that table (in this case, to make rows striped). The problem is that the <tbody> is preceded by <tr> element, which browsers understand as an implicit start of table body, so the following exlicit <tbody> will actually be "nested", which is not valid. Since that first <tr> contains table headers, wrapping it in <thead> is both semantically correct and follows the advertised XHTML 1.1 doctype.
2015-02-06 10:52:55 +03:00
<thead>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<tr>
<th class="name">name</th>
<th class="size">size</th>
<th class="permissions">permissions</th>
</tr>
hgweb: replace implicit <tbody> with explicit <thead> where appropriate Some templates in paper style use <tbody> elements inside <table> to assign a class to "body" part of that table (in this case, to make rows striped). The problem is that the <tbody> is preceded by <tr> element, which browsers understand as an implicit start of table body, so the following exlicit <tbody> will actually be "nested", which is not valid. Since that first <tr> contains table headers, wrapping it in <thead> is both semantically correct and follows the advertised XHTML 1.1 doctype.
2015-02-06 10:52:55 +03:00
</thead>
hgweb: make stripes in directory view with CSS
2013-07-13 17:44:46 +04:00
<tbody class="stripes2">
<tr class="fileline">
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<td class="name"><a href="/file/2ef0ac749a14/">[up]</a></td>
<td class="size"></td>
<td class="permissions">drwxr-xr-x</td>
</tr>
hgweb: make stripes in directory view with CSS
2013-07-13 17:44:46 +04:00
<tr class="fileline">
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<td class="name">
<a href="/file/2ef0ac749a14/da">
<img src="/static/coal-folder.png" alt="dir."/> da/
</a>
<a href="/file/2ef0ac749a14/da/">
</a>
</td>
<td class="size"></td>
<td class="permissions">drwxr-xr-x</td>
</tr>
hgweb: make stripes in directory view with CSS
2013-07-13 17:44:46 +04:00
<tr class="fileline">
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
<td class="filename">
<a href="/file/2ef0ac749a14/foo">
<img src="/static/coal-file.png" alt="file"/> foo
</a>
</td>
<td class="size">4</td>
<td class="permissions">-rw-r--r--</td>
</tr>
hgweb: make stripes in directory view with CSS
2013-07-13 17:44:46 +04:00
</tbody>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</table>
</div>
</div>
web: Made elapsed time calculation dynamic (javascript). This allow safe caching of the pages by the browser and still display the right amount of elapsed time upon page refresh. If javascript is disabled, absolute time is displayed, leaving it readable. All the templates have been updated.
2011-04-28 19:02:39 +04:00
<script type="text/javascript">process_dates()</script>
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
</body>
</html>
stop and restart
killdaemons: take file argument explicitely It makes it easier to use as a generic replacement for kill utility, mostly for Windows tests.
2012-08-21 00:36:51 +04:00
$ "$TESTDIR/killdaemons.py" $DAEMON_PIDS
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
$ hg serve -p $HGPORT -d --pid-file=hg.pid -A access.log
$ cat hg.pid >> $DAEMON_PIDS
Test the access/error files are opened in append mode
tests: use $PYTHON instead of hardcoding python This makes running the testsuite with pypy possible.
2014-10-15 23:35:59 +04:00
$ $PYTHON -c "print len(file('access.log').readlines()), 'log lines written'"
hgweb: fail if an invalid command was supplied in url path (issue4071) Traditionally, the way to specify a command for hgweb was to use url query arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an error (e.g. "400 no such method: badcmd"). But there's also another way to specify a command: as a url path fragment (e.g. "/graph"). Before, hgweb was made forgiving (looks like it was made in cd356f4efd91) and user could put any unknown command in the url. If hgweb couldn't understand it, it would just silently fall back to the default command, which depends on the actual style (e.g. for paper it's shortlog, for monoblue it's summary). This was inconsistent and was breaking some tools that rely on http status codes (as noted in the issue4071). So this patch changes that behavior to the more consistent one, i.e. hgweb will now return "400 no such method: badcmd". So if some tool was relying on having an invalid command return http status code 200 and also have some information, then it will stop working. That is, if somebody typed foobar when they really meant shortlog (and the user was lucky enough to choose a style where the default command is shortlog too), that fact will now be revealed. Code-wise, the changed if block is only relevant when there's no "?cmd" query parameter (i.e. only when command is specified as a url path fragment), and looks like the removed else branch was there only for falling back to default command. With that removed, the rest of the code works as expected: it looks at the command, and if it's not known, raises a proper ErrorResponse exception with an appropriate message. Evidently, there were no tests that required the old behavior. But, frankly, I don't know any way to tell if anyone actually exploited such forgiving behavior in some in-house tool.
2014-09-22 18:46:38 +04:00
14 log lines written
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
static file
serve: don't send any content headers with 304 responses Fixes HTTP protocol violation introduced in e4a5f5db7028. 'hg serve' would show a stacktrace when loading pages that not had been modified. There was test coverage for this, but the wrong response headers wasn't shown and thus not detected.
2013-01-15 23:54:57 +04:00
$ "$TESTDIR/get-with-headers.py" --twice localhost:$HGPORT 'static/style-gitweb.css' - date etag server
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
200 Script output follows
templates: use CSS classes for diff styling Use of inline style for diff styling led to significant browser memory usage on large diffs. Moving the styling into CSS classes corrects this. This patch is based on work from https://bugzilla.mozilla.org/show_bug.cgi?id=766952 and https://hg.mozilla.org/hgcustom/version-control-tools/rev/2c355a580af6
2015-01-07 02:29:02 +03:00
content-length: 5372
serve: don't send any content headers with 304 responses Fixes HTTP protocol violation introduced in e4a5f5db7028. 'hg serve' would show a stacktrace when loading pages that not had been modified. There was test coverage for this, but the wrong response headers wasn't shown and thus not detected.
2013-01-15 23:54:57 +04:00
content-type: text/css
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
css: remove repeated property 'margin' property was repeated for the same selector
2013-04-20 16:46:38 +04:00
body { font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px; margin:10px; }
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
a { color:#0000cc; }
a:hover, a:visited, a:active { color:#880000; }
div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
div.page_header a:visited { color:#0000cc; }
div.page_header a:hover { color:#880000; }
div.page_nav { padding:8px; }
div.page_nav a:visited { color:#0000cc; }
div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
div.page_footer { padding:4px 8px; background-color: #d9d8d1; }
div.page_footer_text { float:left; color:#555555; font-style:italic; }
div.page_body { padding:8px; }
div.title, a.title {
display:block; padding:6px 8px;
font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
}
a.title:hover { background-color: #d9d8d1; }
div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
div.log_body { padding:8px 8px 8px 150px; }
.age { white-space:nowrap; }
span.age { position:relative; float:left; width:142px; font-style:italic; }
div.log_link {
padding:0px 8px;
font-size:10px; font-family:sans-serif; font-style:normal;
position:relative; float:left; width:136px;
}
div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
a.list { text-decoration:none; color:#000000; }
a.list:hover { text-decoration:underline; color:#880000; }
table { padding:8px 4px; }
th { padding:2px 5px; font-size:12px; text-align:left; }
tr.light:hover, .parity0:hover { background-color:#edece6; }
tr.dark, .parity1 { background-color:#f6f6f0; }
tr.dark:hover, .parity1:hover { background-color:#edece6; }
td { padding:2px 5px; font-size:12px; vertical-align:top; }
td.closed { background-color: #99f; }
td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
td.indexlinks { white-space: nowrap; }
td.indexlinks a {
padding: 2px 5px; line-height: 10px;
border: 1px solid;
color: #ffffff; background-color: #7777bb;
border-color: #aaaadd #333366 #333366 #aaaadd;
font-weight: bold; text-align: center; text-decoration: none;
font-size: 10px;
}
td.indexlinks a:hover { background-color: #6666aa; }
div.pre { font-family:monospace; font-size:12px; white-space:pre; }
div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
.linenr { color:#999999; text-decoration:none }
div.rss_logo { float: right; white-space: nowrap; }
div.rss_logo a {
padding:3px 6px; line-height:10px;
border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
color:#ffffff; background-color:#ff6600;
font-weight:bold; font-family:sans-serif; font-size:10px;
text-align:center; text-decoration:none;
}
div.rss_logo a:hover { background-color:#ee5500; }
pre { margin: 0; }
span.logtags span {
padding: 0px 4px;
font-size: 10px;
font-weight: normal;
border: 1px solid;
background-color: #ffaaff;
border-color: #ffccff #ff00ee #ff00ee #ffccff;
}
span.logtags span.tagtag {
background-color: #ffffaa;
border-color: #ffffcc #ffee00 #ffee00 #ffffcc;
}
span.logtags span.branchtag {
background-color: #aaffaa;
border-color: #ccffcc #00cc33 #00cc33 #ccffcc;
}
span.logtags span.inbranchtag {
background-color: #d5dde6;
border-color: #e3ecf4 #9398f4 #9398f4 #e3ecf4;
}
hgweb: add bookmark labels to gitweb theme (based on 4d7cfa1867b5)
2011-04-03 18:44:28 +04:00
span.logtags span.bookmarktag {
background-color: #afdffa;
border-color: #ccecff #46ace6 #46ace6 #ccecff;
}
templates: use CSS classes for diff styling Use of inline style for diff styling led to significant browser memory usage on large diffs. Moving the styling into CSS classes corrects this. This patch is based on work from https://bugzilla.mozilla.org/show_bug.cgi?id=766952 and https://hg.mozilla.org/hgcustom/version-control-tools/rev/2c355a580af6
2015-01-07 02:29:02 +03:00
span.difflineplus { color:#008800; }
span.difflineminus { color:#cc0000; }
span.difflineat { color:#990099; }
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
/* Graph */
div#wrapper {
position: relative;
margin: 0;
padding: 0;
margin-top: 3px;
}
canvas {
position: absolute;
z-index: 5;
top: -0.9em;
margin: 0;
}
ul#nodebgs {
list-style: none inside none;
padding: 0;
margin: 0;
top: -0.7em;
}
ul#graphnodes li, ul#nodebgs li {
height: 39px;
}
ul#graphnodes {
position: absolute;
z-index: 10;
top: -0.8em;
list-style: none inside none;
padding: 0;
}
ul#graphnodes li .info {
display: block;
font-size: 100%;
position: relative;
top: -3px;
font-style: italic;
}
hgweb: side-by-side comparison functionality Adds new web command to the core, ``comparison``, which enables colorful side-by-side change display, which for some might be much easier to work with than the standard line diff output. The idea how to implement comes from the SonicHq extension. The web interface gets a new link to call the comparison functionality. It lets users configure the amount of context lines around change blocks, or to show full files - check help (also in this changeset) for details and defaults. The setting in hgrc can be overridden by adding ``context=<value>`` to the request query string. The comparison creates addressable lines, so as to enable sharing links to specific lines, just as standard diff does. Incorporates updates to all web related styles. Known limitations: * the column diff is done against the first parent, just as the standard diff * this change allows examining diffs for single files only (as I am not sure if examining the whole changeset in this way would be helpful) * syntax highlighting of the output changes is not performed (enabling the highlight extension has no influence on it)
2012-07-08 19:17:02 +04:00
/* Comparison */
.legend {
padding: 1.5% 0 1.5% 0;
}
.legendinfo {
border: 1px solid #d9d8d1;
font-size: 80%;
text-align: center;
padding: 0.5%;
}
.equal {
background-color: #ffffff;
}
.delete {
hgweb: improve colors for comparison page delete: red -> red insert: green -> yellow change: yellow -> gray
2012-07-25 23:49:53 +04:00
background-color: #faa;
color: #333;
hgweb: side-by-side comparison functionality Adds new web command to the core, ``comparison``, which enables colorful side-by-side change display, which for some might be much easier to work with than the standard line diff output. The idea how to implement comes from the SonicHq extension. The web interface gets a new link to call the comparison functionality. It lets users configure the amount of context lines around change blocks, or to show full files - check help (also in this changeset) for details and defaults. The setting in hgrc can be overridden by adding ``context=<value>`` to the request query string. The comparison creates addressable lines, so as to enable sharing links to specific lines, just as standard diff does. Incorporates updates to all web related styles. Known limitations: * the column diff is done against the first parent, just as the standard diff * this change allows examining diffs for single files only (as I am not sure if examining the whole changeset in this way would be helpful) * syntax highlighting of the output changes is not performed (enabling the highlight extension has no influence on it)
2012-07-08 19:17:02 +04:00
}
.insert {
hgweb: improve colors for comparison page delete: red -> red insert: green -> yellow change: yellow -> gray
2012-07-25 23:49:53 +04:00
background-color: #ffa;
hgweb: side-by-side comparison functionality Adds new web command to the core, ``comparison``, which enables colorful side-by-side change display, which for some might be much easier to work with than the standard line diff output. The idea how to implement comes from the SonicHq extension. The web interface gets a new link to call the comparison functionality. It lets users configure the amount of context lines around change blocks, or to show full files - check help (also in this changeset) for details and defaults. The setting in hgrc can be overridden by adding ``context=<value>`` to the request query string. The comparison creates addressable lines, so as to enable sharing links to specific lines, just as standard diff does. Incorporates updates to all web related styles. Known limitations: * the column diff is done against the first parent, just as the standard diff * this change allows examining diffs for single files only (as I am not sure if examining the whole changeset in this way would be helpful) * syntax highlighting of the output changes is not performed (enabling the highlight extension has no influence on it)
2012-07-08 19:17:02 +04:00
}
.replace {
hgweb: improve colors for comparison page delete: red -> red insert: green -> yellow change: yellow -> gray
2012-07-25 23:49:53 +04:00
background-color: #e8e8e8;
hgweb: side-by-side comparison functionality Adds new web command to the core, ``comparison``, which enables colorful side-by-side change display, which for some might be much easier to work with than the standard line diff output. The idea how to implement comes from the SonicHq extension. The web interface gets a new link to call the comparison functionality. It lets users configure the amount of context lines around change blocks, or to show full files - check help (also in this changeset) for details and defaults. The setting in hgrc can be overridden by adding ``context=<value>`` to the request query string. The comparison creates addressable lines, so as to enable sharing links to specific lines, just as standard diff does. Incorporates updates to all web related styles. Known limitations: * the column diff is done against the first parent, just as the standard diff * this change allows examining diffs for single files only (as I am not sure if examining the whole changeset in this way would be helpful) * syntax highlighting of the output changes is not performed (enabling the highlight extension has no influence on it)
2012-07-08 19:17:02 +04:00
}
.comparison {
overflow-x: auto;
}
.header th {
text-align: center;
}
.block {
border-top: 1px solid #d9d8d1;
}
test-hgweb-*: output change fixes from b1d65cb8
2014-01-16 18:23:31 +04:00
.scroll-loading {
-webkit-animation: change_color 1s linear 0s infinite alternate;
-moz-animation: change_color 1s linear 0s infinite alternate;
-o-animation: change_color 1s linear 0s infinite alternate;
animation: change_color 1s linear 0s infinite alternate;
}
@-webkit-keyframes change_color {
from { background-color: #A0CEFF; } to { }
}
@-moz-keyframes change_color {
from { background-color: #A0CEFF; } to { }
}
@-o-keyframes change_color {
from { background-color: #A0CEFF; } to { }
}
@keyframes change_color {
from { background-color: #A0CEFF; } to { }
}
.scroll-loading-error {
background-color: #FFCCCC !important;
}
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
304 Not Modified
hgweb: refresh hgweb.repo on phase change (issue4061) Make hgweb.refresh() also look at phaseroots file (in addition to 00changelog.i file) and reload the repo when os.stat returns different mtime or size than cached, signifying the file was modified. This way if user changes phase of a changeset (secret <-> draft), there's no need to restart hg serve to see the change.
2014-09-27 16:59:55 +04:00
phase changes are refreshed (issue4061)
$ echo bar >> foo
$ hg ci -msecret --secret
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'log?style=raw'
200 Script output follows
# HG changelog
# Node ID 2ef0ac749a14e4f57a5a822464a0902c6f7f448f
changeset: 2ef0ac749a14e4f57a5a822464a0902c6f7f448f
revision: 0
user: test
date: Thu, 01 Jan 1970 00:00:00 +0000
summary: base
branch: default
tag: tip
$ hg phase --draft tip
$ "$TESTDIR/get-with-headers.py" localhost:$HGPORT 'log?style=raw'
200 Script output follows
# HG changelog
# Node ID a084749e708a9c4c0a5b652a2a446322ce290e04
changeset: a084749e708a9c4c0a5b652a2a446322ce290e04
revision: 1
user: test
date: Thu, 01 Jan 1970 00:00:00 +0000
summary: secret
branch: default
tag: tip
changeset: 2ef0ac749a14e4f57a5a822464a0902c6f7f448f
revision: 0
user: test
date: Thu, 01 Jan 1970 00:00:00 +0000
summary: base
tests: unify test-hgweb
2010-09-26 22:41:32 +04:00
errors
$ cat errors.log
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
hgweb: send proper HTTP response after uncaught exception This patch fixes a bug where hgweb would send an incomplete HTTP response. If an uncaught exception is raised when hgweb is processing a request, hgweb attempts to send a generic error response and log that exception. The server defaults to chunked transfer coding. If an uncaught exception occurred, it was sending the error response string / chunk properly. However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to indicate end of the entity body. hgweb was failing to send this last chunk. As a result, properly written HTTP clients would assume more data was coming and they would likely time out waiting for another chunk to arrive. Mercurial's own test harness was paving over the improper HTTP behavior by not attempting to read the response body if the status code was 500. This incorrect workaround was added in faced8f5c2af and has been removed with this patch.
2014-11-28 21:59:02 +03:00
Uncaught exceptions result in a logged error and canned HTTP response
$ "$TESTDIR/killdaemons.py" $DAEMON_PIDS
$ hg --config extensions.hgweberror=$TESTDIR/hgweberror.py serve -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log
$ cat hg.pid >> $DAEMON_PIDS
$ $TESTDIR/get-with-headers.py localhost:$HGPORT 'raiseerror' transfer-encoding content-type
500 Internal Server Error
transfer-encoding: chunked
Internal Server Error (no-eol)
[1]
test-hgweb: fix shutdown race Logfiles weren't necessarily being flushed before being read.
2015-01-24 02:47:04 +03:00
$ "$TESTDIR/killdaemons.py" $DAEMON_PIDS
hgweb: send proper HTTP response after uncaught exception This patch fixes a bug where hgweb would send an incomplete HTTP response. If an uncaught exception is raised when hgweb is processing a request, hgweb attempts to send a generic error response and log that exception. The server defaults to chunked transfer coding. If an uncaught exception occurred, it was sending the error response string / chunk properly. However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to indicate end of the entity body. hgweb was failing to send this last chunk. As a result, properly written HTTP clients would assume more data was coming and they would likely time out waiting for another chunk to arrive. Mercurial's own test harness was paving over the improper HTTP behavior by not attempting to read the response body if the status code was 500. This incorrect workaround was added in faced8f5c2af and has been removed with this patch.
2014-11-28 21:59:02 +03:00
$ head -1 errors.log
.* Exception happened during processing request '/raiseerror': (re)
Uncaught exception after partial content sent
test-hgweb: fix shutdown race Logfiles weren't necessarily being flushed before being read.
2015-01-24 02:47:04 +03:00
$ hg --config extensions.hgweberror=$TESTDIR/hgweberror.py serve -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log
$ cat hg.pid >> $DAEMON_PIDS
hgweb: send proper HTTP response after uncaught exception This patch fixes a bug where hgweb would send an incomplete HTTP response. If an uncaught exception is raised when hgweb is processing a request, hgweb attempts to send a generic error response and log that exception. The server defaults to chunked transfer coding. If an uncaught exception occurred, it was sending the error response string / chunk properly. However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to indicate end of the entity body. hgweb was failing to send this last chunk. As a result, properly written HTTP clients would assume more data was coming and they would likely time out waiting for another chunk to arrive. Mercurial's own test harness was paving over the improper HTTP behavior by not attempting to read the response body if the status code was 500. This incorrect workaround was added in faced8f5c2af and has been removed with this patch.
2014-11-28 21:59:02 +03:00
$ $TESTDIR/get-with-headers.py localhost:$HGPORT 'raiseerror?partialresponse=1' transfer-encoding content-type
200 Script output follows
transfer-encoding: chunked
content-type: text/plain
partial content
Internal Server Error (no-eol)
test-hgweb: fix shutdown race Logfiles weren't necessarily being flushed before being read.
2015-01-24 02:47:04 +03:00
$ "$TESTDIR/killdaemons.py" $DAEMON_PIDS
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
$ cd ..
Reference in New Issue Copy Permalink