From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.142.191.1 with SMTP id o1cs100501wff; Mon, 7 Dec 2009 05:25:47 -0800 (PST) Received: from mr.google.com ([10.140.173.14]) by 10.140.173.14 with SMTP id v14mr2831485rve.20.1260192346961 (num_hops = 1); Mon, 07 Dec 2009 05:25:46 -0800 (PST) Received: by 10.140.173.14 with SMTP id v14mr420628rve.20.1260192345432; Mon, 07 Dec 2009 05:25:45 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.141.14.15 with SMTP id r15ls30907rvi.1.p; Mon, 07 Dec 2009 05:25:44 -0800 (PST) Received: by 10.140.139.2 with SMTP id m2mr1158988rvd.28.1260192343993; Mon, 07 Dec 2009 05:25:43 -0800 (PST) Received: by 10.142.196.1 with SMTP id t1mr1108531wff.2.1260184118723; Mon, 07 Dec 2009 03:08:38 -0800 (PST) Received: by 10.142.196.1 with SMTP id t1mr1108530wff.2.1260184118699; Mon, 07 Dec 2009 03:08:38 -0800 (PST) Return-Path: Received: from mail-pw0-f59.google.com (mail-pw0-f59.google.com [209.85.160.59]) by gmr-mx.google.com with ESMTP id 10si585836pxi.0.2009.12.07.03.08.37; Mon, 07 Dec 2009 03:08:37 -0800 (PST) Received-SPF: pass (google.com: domain of takahashimm@gmail.com designates 209.85.160.59 as permitted sender) client-ip=209.85.160.59; Received: by pwj20 with SMTP id 20so332652pwj.18 for ; Mon, 07 Dec 2009 03:08:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.60.8 with SMTP id i8mr717815wfa.326.1260184117475; Mon, 07 Dec 2009 03:08:37 -0800 (PST) In-Reply-To: <8108c6090912061939h7f2ae70rac675219ed08f2e8@mail.gmail.com> References: <200911241922.13218.ibc@aliax.net> <200911301727.06897.ibc@aliax.net> <8108c6090912061939h7f2ae70rac675219ed08f2e8@mail.gmail.com> Date: Mon, 7 Dec 2009 20:08:37 +0900 Message-ID: <8108c6090912070308w5f58ab44qfb0b4aa31fd44ed8@mail.gmail.com> Subject: Re: Does Rack SPEC states that PATH_INFO must be cut after ";" (semicolon)? From: masayoshi takahashi To: rack-devel@googlegroups.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rack-devel/t/f48d0f995357a3de X-Message-Url: http://groups.google.com/group/rack-devel/msg/f0b51d6df8816bf List-Unsubscribe: , List-Subscribe: , Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI: PSGI (Perl Web Server Gateway Interface Specification; it's Perl version of Rack or WSGI) has no explicit definition of PATH_INFO's separator, and Plack(PSGI reference implementation) keep ";" in PATH_INFO. cf. http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI.pod http://github.com/miyagawa/Plack http://bulknews.typepad.com/blog/2009/10/request_uri-will-be-in-mojo-suppor= t.html Thanks, Masayoshi Takahashi 2009/12/7 masayoshi takahashi : > Hi, > > 2009/12/1 I=F1aki Baz Castillo : >> Hi, could I get some reply to this mail please? I strongly think it coul= d be a >> bug in Rack so I can't understand why it is ignored. >> >> In fact, I've re-checked HTTP and URI BNF grammar and the semicolon ";" = is an >> allowed character into the URI path sections. > > I've read RFC3986 "Uniform Resource Identifier (URI): Generic Syntax". > > * "3.3. Path" in RFC3986: > > =A0 Aside from dot-segments in hierarchical paths, a path segment is > =A0 considered opaque by the generic syntax. =A0URI producing application= s > =A0 often use the reserved characters allowed in a segment to delimit > =A0 scheme-specific or dereference-handler-specific subcomponents. =A0For > =A0 example, the semicolon (";") and equals ("=3D") reserved characters a= re > =A0 often used to delimit parameters and parameter values applicable to > =A0 that segment. =A0The comma (",") reserved character is often used for > =A0 similar purposes. =A0For example, one URI producer might use a segmen= t > =A0 such as "name;v=3D1.1" to indicate a reference to version 1.1 of > =A0 "name", whereas another might use a segment such as "name,1.1" to > =A0 indicate the same. =A0Parameter types may be defined by scheme-specif= ic > =A0 semantics, but in most cases the syntax of a parameter is specific to > =A0 the implementation of the URI's dereferencing algorithm. > > * "5.4. =A0Reference Resolution Examples" and "5.4.1. =A0Normal Examples" > in RFC3986: > > =A0 Within a representation with a well defined base URI of > > =A0 =A0 =A0http://a/b/c/d;p?q > > =A0 a relative reference is transformed to its target URI as follows. > (snip) > =A0 =A0 =A0"g:h" =A0 =A0 =A0 =A0 =A0 =3D =A0"g:h" > =A0 =A0 =A0"g" =A0 =A0 =A0 =A0 =A0 =A0 =3D =A0"http://a/b/c/g" > =A0 =A0 =A0"./g" =A0 =A0 =A0 =A0 =A0 =3D =A0"http://a/b/c/g" > =A0 =A0 =A0"g/" =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"http://a/b/c/g/" > =A0 =A0 =A0"/g" =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"http://a/g" > =A0 =A0 =A0"//g" =A0 =A0 =A0 =A0 =A0 =3D =A0"http://g" > =A0 =A0 =A0"?y" =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"http://a/b/c/d;p?y" > =A0 =A0 =A0"g?y" =A0 =A0 =A0 =A0 =A0 =3D =A0"http://a/b/c/g?y" > =A0 =A0 =A0"#s" =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"http://a/b/c/d;p?q#s" > =A0 =A0 =A0"g#s" =A0 =A0 =A0 =A0 =A0 =3D =A0"http://a/b/c/g#s" > =A0 =A0 =A0"g?y#s" =A0 =A0 =A0 =A0 =3D =A0"http://a/b/c/g?y#s" > =A0 =A0 =A0";x" =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"http://a/b/c/;x" > =A0 =A0 =A0"g;x" =A0 =A0 =A0 =A0 =A0 =3D =A0"http://a/b/c/g;x" > =A0 =A0 =A0"g;x?y#s" =A0 =A0 =A0 =3D =A0"http://a/b/c/g;x?y#s" > (snip) > > I think ";" is used separator like "?" in this document. > > And "2.3. =A0Specific Schemes and their Syntactic Categories" in RFC 1808= : > > =A0 NOTE: Section 5 of RFC 1738 specifies that the question-mark > =A0 =A0 =A0 =A0 character ("?") is allowed in an ftp or file path segment= . > =A0 =A0 =A0 =A0 However, this is not true in practice and is believed to = be an > =A0 =A0 =A0 =A0 error in the RFC. =A0Similarly, RFC 1738 allows the reser= ved > =A0 =A0 =A0 =A0 character semicolon (";") within an http path segment, bu= t does > =A0 =A0 =A0 =A0 not define its semantics; the correct semantics are as de= fined > =A0 =A0 =A0 =A0 by this document for . > > (notice: RFC1808 is obsoleted by RFC3986) > > I think ";" =A0is confused. So Rack SPEC should not mention about ";". > But, in the real applications like Thin or others, it's not bad > that ";" is treated as ordinary character, not PATH separator. > > Hope this help, > > Masayoshi Takahashi >