Received: by 10.224.19.144 with SMTP id a16mr36070qab.7.1236881986654;
        Thu, 12 Mar 2009 11:19:46 -0700 (PDT)
Return-Path: <scyt...@gmail.com>
Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.144])
        by gmr-mx.google.com with ESMTP id 18si46663qyk.1.2009.03.12.11.19.45;
        Thu, 12 Mar 2009 11:19:45 -0700 (PDT)
Received-SPF: pass (google.com: domain of scyt...@gmail.com designates 74.125.92.144 as permitted sender) client-ip=74.125.92.144;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of scyt...@gmail.com designates 74.125.92.144 as permitted sender) smtp.mail=scyt...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by qw-out-1920.google.com with SMTP id 9so854634qwj.26
        for <rack-devel@googlegroups.com>; Thu, 12 Mar 2009 11:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=4zoijP/+2skOkn54uCiV1CLWwSryHfDfx8nXPYTka3o=;
        b=t4EGyGFjWzuhyrjTr1d52q+a5cpZvjnGt65eKtJOXjU6BanHdGFFoO11tuR5RbMAbq
         TFWn+mz/VrwU+m6Mj7wnPXi81QmdNN+hY2xsm7pNM12Jw2FYARcxEM0FuYqdPKdHLbL5
         gjOiiJdMNSXe08tXjKlzcpB+T/JTKA6KjzWtQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=hsslTjhLzEs585W7bWJNzgGTLxWunq+Q3kY1LNJH0SoDLnAviAXPnk8f65T3YzuLNj
         y6b/Le4FZ7WnZhwaQNUw0ca1ZJgj9NMv5fEfLsuv4Frpz/POMPlKWSpQ1gR+WzMNx6W2
         FK1QEw6WZp0wjYd5WmABfiX+C+N0bn8yIvGm8=
MIME-Version: 1.0
Received: by 10.229.74.80 with SMTP id t16mr324030qcj.20.1236881984896; Thu, 
	12 Mar 2009 11:19:44 -0700 (PDT)
In-Reply-To: <e270099f-468e-4fbb-87e8-efbb63f3dcb0@a12g2000yqm.googlegroups.com>
References: <2da6cac5-03ac-4bae-bc9f-ccdac6d9da9f@r28g2000vbp.googlegroups.com>
	 <17eac67c0903081052w299c36a2y8f7d4403f807d...@mail.gmail.com>
	 <m2fxhnu253....@gmail.com>
	 <f732822d0903101601p594f63c3uc61857b285d83...@mail.gmail.com>
	 <07bdc9b9-b0f7-435a-9b2c-19b478985...@d19g2000yqb.googlegroups.com>
	 <m2tz60rzpu....@gmail.com>
	 <e270099f-468e-4fbb-87e8-efbb63f3d...@a12g2000yqm.googlegroups.com>
Date: Thu, 12 Mar 2009 11:19:44 -0700
Message-ID: <5a9d52bd0903121119l34735249qd8c941933472f...@mail.gmail.com>
Subject: Re: Bug: WEBrick handler does not set the unescaped PATH_INFO
From: Scytrin dai Kinthra <scyt...@gmail.com>
To: rack-devel@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'd promote on this piece to leave it encoded so that it isn't broken
as standard.
Following "standard convention" is nice, but I'd rather follow the standard=
s.

On Wed, Mar 11, 2009 at 12:55, candlerb <b.cand...@pobox.com> wrote:
>
> On Mar 11, 12:49=C2=A0pm, Christian Neukirchen <chneukirc...@gmail.com>
> wrote:
>> candlerb <b.cand...@pobox.com> writes:
>> > Rack can specify whatever behaviour it likes, but the problem if we
>> > say that handlers should *not* decode PATH_INFO is that in some cases
>> > it may have already been done (e.g. when Rack is running as a CGI).
>>
>> When would it be useful to have it not decoded?
>
> /invoices/2009%2F1234/print
>
> From RFC 3986:
>
> =C2=A0"The purpose of reserved characters is to provide a set of
> delimiting
> =C2=A0 characters that are distinguishable from other data within a URI.
> =C2=A0 URIs that differ in the replacement of a reserved character with
> its
> =C2=A0 corresponding percent-encoded octet are not equivalent. =C2=A0Perc=
ent-
> =C2=A0 encoding a reserved character, or decoding a percent-encoded octet
> =C2=A0 that corresponds to a reserved character, will change how the URI
> is
> =C2=A0 interpreted by most applications."
>
> Or consider this:
>
> helpers do
> =C2=A0def build_path(*path_components)
> =C2=A0 =C2=A0path_components.map { |c| escape(c) }.join("/")
> =C2=A0end
>
> =C2=A0# If the path has already been decoded, we cannot
> =C2=A0# implement the inverse function accurately:
> =C2=A0def split_path(path)
> =C2=A0 =C2=A0path.split("/").map { |c| unescape(c) }
> =C2=A0end
> end
>
> However there are sufficiently many broken HTTP implementations around
> that can't parse this properly, that it would be unsurprising if Rack
> were similarly broken. So I won't push too hard for it.
>



--=20
stadik.net