Re: Does Rack SPEC states that PATH_INFO must be cut after ";" (semicolon)?

[masayoshi takahashi <takahashimm@gmail.com>]

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-support.html

Thanks,

Masayoshi Takahashi


2009/12/7 masayoshi takahashi <takahashimm@gmail.com>:
> Hi,
>
> 2009/12/1 Iñaki Baz Castillo <ibc@aliax.net>:
>> Hi, could I get some reply to this mail please? I strongly think it could 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:
>
>   Aside from dot-segments in hierarchical paths, a path segment is
>   considered opaque by the generic syntax.  URI producing applications
>   often use the reserved characters allowed in a segment to delimit
>   scheme-specific or dereference-handler-specific subcomponents.  For
>   example, the semicolon (";") and equals ("=") reserved characters are
>   often used to delimit parameters and parameter values applicable to
>   that segment.  The comma (",") reserved character is often used for
>   similar purposes.  For example, one URI producer might use a segment
>   such as "name;v=1.1" to indicate a reference to version 1.1 of
>   "name", whereas another might use a segment such as "name,1.1" to
>   indicate the same.  Parameter types may be defined by scheme-specific
>   semantics, but in most cases the syntax of a parameter is specific to
>   the implementation of the URI's dereferencing algorithm.
>
> * "5.4.  Reference Resolution Examples" and "5.4.1.  Normal Examples"
> in RFC3986:
>
>   Within a representation with a well defined base URI of
>
>      http://a/b/c/d;p?q
>
>   a relative reference is transformed to its target URI as follows.
> (snip)
>      "g:h"           =  "g:h"
>      "g"             =  "http://a/b/c/g"
>      "./g"           =  "http://a/b/c/g"
>      "g/"            =  "http://a/b/c/g/"
>      "/g"            =  "http://a/g"
>      "//g"           =  "http://g"
>      "?y"            =  "http://a/b/c/d;p?y"
>      "g?y"           =  "http://a/b/c/g?y"
>      "#s"            =  "http://a/b/c/d;p?q#s"
>      "g#s"           =  "http://a/b/c/g#s"
>      "g?y#s"         =  "http://a/b/c/g?y#s"
>      ";x"            =  "http://a/b/c/;x"
>      "g;x"           =  "http://a/b/c/g;x"
>      "g;x?y#s"       =  "http://a/b/c/g;x?y#s"
> (snip)
>
> I think ";" is used separator like "?" in this document.
>
> And "2.3.  Specific Schemes and their Syntactic Categories" in RFC 1808:
>
>   NOTE: Section 5 of RFC 1738 specifies that the question-mark
>         character ("?") is allowed in an ftp or file path segment.
>         However, this is not true in practice and is believed to be an
>         error in the RFC.  Similarly, RFC 1738 allows the reserved
>         character semicolon (";") within an http path segment, but does
>         not define its semantics; the correct semantics are as defined
>         by this document for <params>.
>
> (notice: RFC1808 is obsoleted by RFC3986)
>
> I think ";"  is 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
>