threads / patch / 2893

patchGIT: Support [address] in URLs

Subject: [PATCH] GIT: Support [address] in URLs

## tl;dr

13 messages between Dec 21, 2005 and Dec 22, 2005. Diffs are folded; open one to read it.

replies: 12people: 5as markdown or json

YOSHIFUJI Hideaki / 吉藤英明· Dec 21, 2005, 10:23 UTC · lore
Hello.
Allow address enclosed by [] in URLs, like:
   git push '[3ffe:ffff:...:1]:GIT/git'
or
   git push 'ssh://[3ffe:ffff:...:1]/GIT/git'
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Show changes to connect.c +21 −9
diff --git a/connect.c b/connect.c
index 93f6f80..49f93c6 100644
--- a/connect.c
+++ b/connect.c
@@ -561,7 +561,8 @@ int git_connect(int fd[2], char *url, co
 {
 	char command[1024];
 	char *host, *path = url;
-	char *colon = NULL;
+	char *end;
+	int c;
 	int pipefd[2][2];
 	pid_t pid;
 	enum protocol protocol = PROTO_LOCAL;
@@ -571,15 +572,26 @@ int git_connect(int fd[2], char *url, co
 		*host = '\0';
 		protocol = get_protocol(url);
 		host += 3;
-		path = strchr(host, '/');
-	}
-	else {
+		c = '/';
+	} else {
 		host = url;
-		if ((colon = strchr(host, ':'))) {
-			protocol = PROTO_SSH;
-			*colon = '\0';
-			path = colon + 1;
-		}
+		c = ':';
+	}
+
+	if (host[0] == '[') {
+		end = strchr(host + 1, ']');
+		if (end) {
+			*end = 0;
+			end++;
+			host++;
+		} else
+			end = host;
+	} else
+		end = host;
+
+	if ((path = strchr(end, c)) && c == ':') {
+		protocol = PROTO_SSH;
+		*path++ = '\0';
 	}
 
 	if (!path || !*path)

-- 
YOSHIFUJI Hideaki @ USAGI Project  <yoshfuji@linux-ipv6.org>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
Junio C Hamano· Dec 21, 2005, 22:16 UTC · re: YOSHIFUJI Hideaki / 吉藤英明 · lore

Re: [PATCH] GIT: Support [address] in URLs

[somehow the first reply seems to have been lost]
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> Allow address enclosed by [] in URLs, like:
>    git push '[3ffe:ffff:...:1]:GIT/git'
> or
>    git push 'ssh://[3ffe:ffff:...:1]/GIT/git'

I am not familiar with how things are done in ipv6 land, but I wonder if the former is consistent with the existing practice.

That is, how does one do something like this, with an ipv6 literal address?

	telnet 127.0.0.1 80
Is it done like this
	telnet '[::1]' 80
or
	telnet '::1' 80
Your patch suggests the former, but I just wanted to make sure.

The latter "ssh://[...]" looks like RFC 3986, and I do not have problems with.

YOSHIFUJI Hideaki / 吉藤英明· Dec 21, 2005, 22:20 UTC · lore

Re: [PATCH] GIT: Support [address] in URLs

In article <7vr7866uww.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 12:45:51 -0800), Junio C Hamano <junkio@cox.net> says:
Show 13 quoted lines
> That is, how does one do something like this, with an ipv6
> literal address?
> 
> 	telnet 127.0.0.1 80
> 
> Is it done like this
> 
> 	telnet '[::1]' 80
> 
> or
> 	telnet '::1' 80
> 
> Your patch suggests the former, but I just wanted to make sure.
In this case (telnet), we do the latter.
But, we definitely do
        scp file1 file2 ... '[3ffe:ffff:...:1]:/tmp/'
like
        scp file1 file2 ... remote.example.com:/tmp/
Hope this helps.
--yoshfuji
Junio C Hamano· Dec 21, 2005, 23:03 UTC · lore

Re: [PATCH] GIT: Support [address] in URLs

YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> But, we definitely do
>         scp file1 file2 ... '[3ffe:ffff:...:1]:/tmp/'
> like
>         scp file1 file2 ... remote.example.com:/tmp/
Thanks.
YOSHIFUJI Hideaki / 吉藤英明· Dec 21, 2005, 23:08 UTC · lore

Re: [PATCH] GIT: Support [address] in URLs

In article <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 14:52:59 -0800), Junio C Hamano <junkio@cox.net> says:
> This is the second reply to Yoshifuji-san today that did not
> come back to me from the list (but I did get it back from my ISP
> due to BCCing myself), so I am resending.
I got all of them; with and without my Japanese name on To:.
--yoshfuji
Junio C Hamano· Dec 21, 2005, 23:24 UTC · re: YOSHIFUJI Hideaki / 吉藤英明 · lore

[OT] western cultural imperialism at vger?

YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
Show 7 quoted lines
> In article <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 14:52:59 -0800), Junio C Hamano <junkio@cox.net> says:
>
>> This is the second reply to Yoshifuji-san today that did not
>> come back to me from the list (but I did get it back from my ISP
>> due to BCCing myself), so I am resending.
>
> I got all of them; with and without my Japanese name on To:.

Your "oops this is the corrected patch" message appeared in my mailbox only once, which suggests vger discarded it. It does not appear on marc nor gmane archive either.

It seems to me that vger drops messages whose content-type is "text/plain; charset=iso-2022-jp"; this western cultural imperialism is inexcusable -- the list accepts iso-8859-1 just fine, so it is not like it is us-ascii only. It just does not like iso-2022-jp.

Nah, I am just joking about the "imperialism" part, but I think that is what is happening.

Most of your messages, although you have your Japanese name on the From: header line, are charset=us-ascii, and indeed the body of them are us-ascii only, and is flowing on the list just fine. The "oops this is the corrected patch" message from you was done as a reply to your own message, which started with something like this (Japanese omitted for obvious reasons):

    In article <20051221.192342.132228413.yoshfuji@linux-ipv6.org> (at Wed, 21 Dec 2005 19:23:42 +0900 (JST)), YOSHIFUJI Hideaki / [J][J][J][J] <yoshfuji@linux-ipv6.org> says:
    > Hello.
    > 
    > Allow address enclosed by [] in URLs, like:
    >    git push '[3ffe:ffff:...:1]:GIT/git'
    > or
    >    git push 'ssh://[3ffe:ffff:...:1]/GIT/git'
    > 
    > Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    oops, this is not correct. Please use this instead.

Which made your MUA to send it in iso-2022-jp, and I suspect that is why I saw it only once, direct delivery.

David S. Miller· Dec 21, 2005, 23:29 UTC · re: Junio C Hamano · lore

Re: [OT] western cultural imperialism at vger?

From: Junio C Hamano <junkio@cox.net>
Date: Wed, 21 Dec 2005 15:24:39 -0800
Show 5 quoted lines
> It seems to me that vger drops messages whose content-type is
> "text/plain; charset=iso-2022-jp"; this western cultural
> imperialism is inexcusable -- the list accepts iso-8859-1 just
> fine, so it is not like it is us-ascii only.  It just does not
> like iso-2022-jp.
No, we filter for certain multibyte characters.

If you can teach Matti Aarnio and myself how to speak Japanese, Korean, Russian, and Chinese, and thus be able to build proper regexp's for SPAM in those languages, we'll happily do it.

Krzysztof Halasa· Dec 21, 2005, 23:38 UTC · re: Junio C Hamano · lore

Re: [OT] western cultural imperialism at vger?

Junio C Hamano <junkio@cox.net> writes:
> It seems to me that vger drops messages whose content-type is
> "text/plain; charset=iso-2022-jp";

I think (a part of) the above line is in spam filter on vger. They use a simple substring match, details are on http://vger.kernel.org.

They could probably be able to reject inbound SMTP transfer and not silently drop the message later.

-- 
Krzysztof Halasa
David S. Miller· Dec 21, 2005, 23:46 UTC · re: Krzysztof Halasa · lore

Re: [OT] western cultural imperialism at vger?

From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Thu, 22 Dec 2005 00:38:27 +0100
> I think (a part of) the above line is in spam filter on vger. They
> use a simple substring match, details are on http://vger.kernel.org.
Right, http://vger.kernel.org/majordomo-taboos.txt

There are content type regexps in there as well as checks for specific multi-byte character sequences.

David S. Miller· Dec 21, 2005, 23:26 UTC · re: YOSHIFUJI Hideaki / 吉藤英明 · lore

Re: [PATCH] GIT: Support [address] in URLs

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 22 Dec 2005 08:08:28 +0900 (JST)
Show 7 quoted lines
> In article <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 14:52:59 -0800), Junio C Hamano <junkio@cox.net> says:
> 
> > This is the second reply to Yoshifuji-san today that did not
> > come back to me from the list (but I did get it back from my ISP
> > due to BCCing myself), so I am resending.
> 
> I got all of them; with and without my Japanese name on To:.

The vger.kernel.org spam filter filters out all non-ascii character sets. We have to do this because Matti and myself do all of the filtering by hand, and we do not understand so many languages as to be able to make sensible filters for spam in languages such as Japanese, Korean, Chinese, Russian, etc. so we just filter them all.

I've asked people, such as Yoshifuji-san, on a number of occaisions if they would mind not including Japanese characters (even if it is their name in their FROM: field) in postings to the lists.

As long as they continue to do so, replies to their postings will be filterd when their From: field ends up in the body of the posting. I edit the Japanese characters out by hand when I make replies to such postings, and that is why my responses show up.

This is a pain, but no better solutions have been suggested.  Before
anyone responds: 1) making the lists subscriber-only is not an option
2) Bayesian filters are hard to integrate into our setup but we are
exploring ways to make that a reality at some point nevertheless.
YOSHIFUJI Hideaki / 吉藤英明· Dec 21, 2005, 23:59 UTC · re: David S. Miller · lore

Re: [PATCH] GIT: Support [address] in URLs

In article <20051221.152648.122640664.davem@davemloft.net> (at Wed, 21 Dec 2005 15:26:48 -0800 (PST)), "David S. Miller" <davem@davemloft.net> says:
Show 5 quoted lines
> The vger.kernel.org spam filter filters out all non-ascii character
> sets.  We have to do this because Matti and myself do all of the
> filtering by hand, and we do not understand so many languages as to be
> able to make sensible filters for spam in languages such as Japanese,
> Korean, Chinese, Russian, etc. so we just filter them all.
Too bad...

Well, I know some Japanese people kill all messages with non-Japanese (usually English) subject... It is too bad, too...

> This is a pain, but no better solutions have been suggested.  Before
> anyone responds: 1) making the lists subscriber-only is not an option
> 2) Bayesian filters are hard to integrate into our setup but we are
> exploring ways to make that a reality at some point nevertheless.

Can I help you somehow? E.g. if you give me an account on vger, I happily try to find the way to setup bayesian filter(s) on them.

Regards,
--yoshfuji
David S. Miller· Dec 22, 2005, 00:08 UTC · re: YOSHIFUJI Hideaki / 吉藤英明 · lore

Re: [PATCH] GIT: Support [address] in URLs

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 22 Dec 2005 08:59:17 +0900 (JST)
> Can I help you somehow?
> E.g. if you give me an account on vger, I happily try to find the way to
> setup bayesian filter(s) on them.
You are expert with Zmailer+Majordomo? :-)

Sure, it is no problem to setup Bayesian filter with sendmail, qmail, Exim et al. with standard mailing list software. But doing it with the Zmailer and Majordomo setup we have is non-trivial.

Matti, non-ascii filtering really becomes big enough pain enough to fix. I can do the leg work if you can provide some pointers and what you know so far.

Thanks.
Daniel Barkalow· Dec 22, 2005, 16:48 UTC · re: David S. Miller · lore

Re: [PATCH] GIT: Support [address] in URLs

On Wed, 21 Dec 2005, David S. Miller wrote:
> This is a pain, but no better solutions have been suggested.  Before
> anyone responds: 1) making the lists subscriber-only is not an option
> 2) Bayesian filters are hard to integrate into our setup but we are
> exploring ways to make that a reality at some point nevertheless.

Would it work to strip out all of the characters which are only in the disallowed character set, change the character set to ascii, and check the message like that? (Of course, empty or substantially reduced messages should be discarded instead) It looks like the non-spam in these character sets only has a few non-ascii characters, and those are transliterated into ascii nearby anyway, and I doubt that there's much spam in non-ascii with only a few characters in some other character set that wouldn't be obvious in some other way after those characters were removed.

	-Daniel
*This .sig left intentionally blank*

← back to recent threads