All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jakub Narębski" <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Wagner <accounts@mwagner.org>,
	Peter Krefting <peter@softwolves.pp.se>,
	git <git@vger.kernel.org>
Subject: Re: [PATCH/RFC] Gitweb: Convert UTF-8 encoded file names
Date: Tue, 27 May 2014 16:18:49 +0200	[thread overview]
Message-ID: <53849EC9.1010304@gmail.com> (raw)
In-Reply-To: <xmqq4n0pbqnc.fsf@gitster.dls.corp.google.com>

W dniu 2014-05-16 19:05, Junio C Hamano pisze:
> Jakub Narębski <jnareb@gmail.com> writes:
> 
>>> Correct, but is "where does it appear" the question we are
>>> primarily interested in, wrt this breakage and its fix?
>>
>> That of course depends on how we want to test gitweb output.
>> The simplest solution, comparing with known output with perhaps
>> fragile / variable elements masked out could be done quickly...
>> but changes in output (even if they don't change functionality,
>> or don't change visible output) require regenerating test cases
>> (expected output) to test against - which might be source of
>> errors in test suite.
> 
> I agree with your "to test it fully, we need extra dependencies",
> but my point is that it does not have to be a full "HTML-validating,
> picking the expected attribute via XPATH matching" kind of test if
> what we want is only to add a new test to protect this particular
> fix from future breakages.
> 
> For example, I think it is sufficient to grep for 'href="...%xx%xx"'
> in the output after preparing a sample tree with one entry to show.
> The expected substring either exists (in which case we got it
> right), or it doesn't (in which case we are showing garbage).  Of
> course that depends on the assumption that its output is not too
> heavily contaminated with volatile parts outside our control, as I
> already mentioned in the message you are responding to.
> 
> But it all depends on "if" we wanted to add a new test ;-)

I tried to add such simple test to t9502, but instead of tests
failing with current version, the test setup fails but succeeds
(i.e. test library says that it failed, but manual examination
shows that everything is O.K.).

-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Subject: [PATCH/RFC] gitweb test: Test proper encoding of non US-ASCII filenames in output (WIP)

This t9502 test is intended to test for proper encoding of non
US-ASCII filenames (i.e. UTF-8 filenames) in generated links (which
need some form of URI encoding) and in generated HTML (which needs
HTML encoding / escaping).

For now it tests only 'tree' view (though incidentally it also tests
UTF-8 in commit subject), as this was the action where reportedly
there was bug in link encoding: $t{'name'} coming from the
"git ls-tree -z ..." command via @ntries array was not marked as
UTF-8, making Perl assume that it is in internal Perl format
i.e. iso-8859-1 encoding and URI-escaping it as if it was in
iso-8859-1 encoding (e.g. "Gütekriterien.txt" in UTF-8 is
"Gütekriterien.txt" if treated as iso-8859-1, and it then
encodes to "G%C3%83%C2%BCtekriterien.txt" instead of correct
"G%C3%BCtekriterien.txt").

UNFORTUNATELY test does not fail as it should, even though the issue
was not fixed... OTOH it fails in setup though it is successful.

Reported-by: Michael Wagner <accounts@mwagner.org>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
---
 t/t9502-gitweb-standalone-parse-output.sh |   34 +++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/t/t9502-gitweb-standalone-parse-output.sh b/t/t9502-gitweb-standalone-parse-output.sh
index 86dfee2..37246a3 100755
--- a/t/t9502-gitweb-standalone-parse-output.sh
+++ b/t/t9502-gitweb-standalone-parse-output.sh
@@ -201,4 +201,38 @@ test_expect_success 'xss checks' '
 	xss "a=rss&p=foo.git&f=$TAG"
 '
 
+link_check () {
+	grep -F   "%3C__%C2%A3%C3%A5%C3%AB%C3%AE%C3%B1%C3%B2%C3%BB%C3%BD%C2%B6" \
+		gitweb.body &&
+	! grep -F "%3C__%A3%E5%EB%EE%F1%F2%FB%FD%B6" \
+		gitweb.body
+}
+
+test_expect_success 'prepare UTF-8 output tests' '
+	FILENAME="<__£åëîñòûý¶  +;?&__>" &&
+	test_commit "Adding $FILENAME" "$FILENAME" "$FILENAME contents"
+'
+
+test_expect_success 'check URI-escaped UTF-8 filename in query-params link' '
+	cat >>gitweb_config.perl <<-\EOF &&
+	$feature{"pathinfo"}{"default"} = [0];
+	EOF
+	gitweb_run "p=.git;a=tree" &&
+	link_check
+'
+
+test_expect_success 'check URI-escaped UTF-8 filename in path_info link' '
+	cat >>gitweb_config.perl <<-\EOF &&
+	$feature{"pathinfo"}{"default"} = [1];
+	EOF
+	gitweb_run "" "/.git/tree" &&
+	link_check
+'
+
+test_expect_success 'check HTML-escaped UTF-8 filename in body' '
+	gitweb_run "p=.git;a=tree" &&
+	grep -F "&lt;__£åëîñòûý¶  +;?&amp;__&gt;" gitweb.body &&
+	! grep -F  "<__£åëîñòûý¶  +;?&__>" gitweb.body
+'
+
 test_done
-- 
1.7.1


 

  reply	other threads:[~2014-05-27 14:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14 18:41 [PATCH/RFC] Gitweb: Convert UTF-8 encoded file names Michael Wagner
2014-05-14 21:57 ` Junio C Hamano
2014-05-14 22:25   ` Jakub Narębski
2014-05-15  5:08     ` Michael Wagner
2014-05-15  9:04       ` Peter Krefting
2014-05-15 17:24         ` Junio C Hamano
2014-05-15 18:48         ` Michael Wagner
2014-05-15 19:28           ` Jakub Narębski
2014-05-15 19:37             ` Jakub Narębski
2014-05-15 19:38             ` Junio C Hamano
2014-05-15 20:45               ` Jakub Narębski
2014-05-16  1:26                 ` Junio C Hamano
2014-05-16  7:54                   ` Jakub Narębski
2014-05-16 17:05                     ` Junio C Hamano
2014-05-27 14:18                       ` Jakub Narębski [this message]
2014-05-16 18:17                     ` Junio C Hamano
2014-05-27 14:22             ` [PATCH] gitweb: Harden UTF-8 handling in generated links Jakub Narębski
2014-06-04 15:41               ` Michael Wagner
2014-06-04 18:47                 ` Jakub Narębski
2014-06-04 20:47                   ` Michael Wagner
2015-03-23 21:35                   ` What's cooking in git.git (Mar 2015, #08; Mon, 23) Junio C Hamano
2014-12-17 14:18                     ` [PATCH v4] remote: add --fetch and --both options to set-url Peter Wu
2014-12-17 14:32                       ` Jeff King
2014-12-17 14:42                         ` Peter Wu
2014-12-17 22:31                       ` Junio C Hamano
2015-03-24 22:21                       ` What's cooking in git.git (Mar 2015, #08; Mon, 23) Junio C Hamano
2015-03-26 16:18                         ` Jeff King
2015-03-24 20:02                     ` Junio C Hamano
2015-03-24 20:04                       ` Jeff King
2015-03-24 20:08                     ` Junio C Hamano
2015-03-24 23:37                     ` Junio C Hamano
2015-03-24 22:26                   ` Junio C Hamano
2015-03-25  0:37                     ` Jakub Narębski
2015-03-25  1:05                       ` Junio C Hamano
2014-05-15 12:32       ` [PATCH/RFC] Gitweb: Convert UTF-8 encoded file names Jakub Narębski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53849EC9.1010304@gmail.com \
    --to=jnareb@gmail.com \
    --cc=accounts@mwagner.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peter@softwolves.pp.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.