Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 22995 invoked from network); 22 Sep 2006 09:29:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Sep 2006 09:29:10 -0000 Received: (qmail 35638 invoked by uid 500); 22 Sep 2006 09:29:06 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 35605 invoked by uid 500); 22 Sep 2006 09:29:06 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 35594 invoked by uid 99); 22 Sep 2006 09:29:06 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Sep 2006 02:29:06 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=smallsmallorgan@gmail.com; domainkeys=good Authentication-Results: idunn.apache.osuosl.org smtp.mail=smallsmallorgan@gmail.com; spf=pass X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates 64.233.162.207 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from [64.233.162.207] ([64.233.162.207:48975] helo=nz-out-0102.google.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id FD/63-06791-FDCA3154 for ; Fri, 22 Sep 2006 02:29:04 -0700 Received: by nz-out-0102.google.com with SMTP id v1so594972nzb for ; Fri, 22 Sep 2006 02:29:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=k96OpaHrdYuHxaACZl5dxdpRtUtMGvLZ6YdrOfWKkN9C8iisO0JGw+eZn4PBTRbluTs0g6RGJD8xPIIeZuhNIoT0HUpuhjet1fOF/2EEAX0FPyAmvEMT5uDRpU87SrdcJzVObAsjDo95k8qwxbm4L7PcO2qGDT/qxACKP2UOyrg= Received: by 10.65.251.17 with SMTP id d17mr177751qbs; Fri, 22 Sep 2006 02:29:00 -0700 (PDT) Received: by 10.65.15.3 with HTTP; Fri, 22 Sep 2006 02:29:00 -0700 (PDT) Message-ID: <473c46620609220229y383458a0q85d84daee90e8cc6@mail.gmail.com> Date: Fri, 22 Sep 2006 17:29:00 +0800 From: "Spark Shen" To: harmony-dev@incubator.apache.org Subject: Re: [Non-bug difference]? JIRA-1126 In-Reply-To: <26c14c2a0609210438n79f8800fj7738742943c065e3@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16899_29687771.1158917340185" References: <45124842.2050904@gmail.com> <45124957.9020905@gmail.com> <26c14c2a0609210438n79f8800fj7738742943c065e3@mail.gmail.com> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_16899_29687771.1158917340185 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 2006/9/21, Oleg Khaschansky : > > I'd like to quote RFC 2396 here: > > "The URI syntax does not require that the scheme-specific-part have > any general structure or set of semantics which is common among all > URI. However, a subset of URI do share a common syntax for > representing hierarchical relationships within the namespace. This > "generic URI" syntax consists of a sequence of four main components: > > ://? > > each of which, except , may be absent from a particular URI." > > ... > > "We use the term to refer to both the and > constructs, since they are mutually exclusive for any > given URI and can be parsed as a single component." > > So "file://C:/1.txt" appears to be a valid URI of the following kind: > ://, where is an . I still think this is a bug of RI. According to RFC2396, to be recognized as server-based authority, the uri should obey a more formal rule(than registry-based authority). Apparently, file://C:/1.txt can only be recognized as a registry-based authority. [cite] Otherwise this method attempts once more to parse the authority component into user-information, host, and port components, and throws an exception describing why the authority component could not be parsed in that way. This method is provided because the generic URI syntax specified in RFC 2396 cannot always distinguish a malformed server-based authority from a legitimate registry-based authority. [cite] IMHO, this paragraph of depiction aims to say that this method is used to strictly distinguish server-based authority from a legitimate registry-based authority. And will throw exception if the URI is not a server-based authority. But RI apparently do not behave as spec depicts, so I suggest to change the component to non-bug difference. Best regards This means that #1126 is, actually, a bug. Am I correct? > > > On 9/21/06, Spark Shen wrote: > > [snip] > > > > > > > > > >>Vladimir Ivanov > > > > > > >>unit test. > > > >>Seems, that patch will be system dependent (special handling for Win > > > should be added) > > [snip] > > And I agree with Vladimir Ivanov here, on Win-platform, special handling > > for file system is needed. > > > > Best regards > > > > -- > > Spark Shen > > China Software Development Lab, IBM > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org > For additional commands, e-mail: harmony-dev-help@incubator.apache.org > > -- Spark Shen China Software Development Lab, IBM ------=_Part_16899_29687771.1158917340185--