require 'rack'
  app = lambda {|env| [200, {}, [env['PATH_INFO']]] }
  Rack::Handler::WEBrick.run(app, :Port => 8080)

A request to 'http://localhost:8080/percent%3Aencoding' returns:

  percent:encoding

Rather than:

  percent%3Aencoding

http://hoohoo.ncsa.uiuc.edu/cgi/env.html

Cheers,
Sam

However this may differ from CGI practice. Let me just test this with
an old-skool CGI under apache 2.2.8 (Ubuntu Hardy):

#!/usr/bin/ruby
puts "Content-Type: text/plain"
puts
puts "PATH_INFO = #{ENV['PATH_INFO'].inspect}"

Hmm, strange.
    http://localhost/cgi-bin/test-cgi
    http://localhost/cgi-bin/test-cgi/foo
    http://localhost/cgi-bin/test-cgi/foo/bar
all work as expected. But
    http://localhost/cgi-bin/test-cgi/foo%2Fbar
gives a 404 error!

    http://localhost/cgi-bin/test.cgi/foo%2Abar
does work, and gives a result of
    PATH_INFO = "/foo*bar"

Interestingly, with this test, Firefox updated its URL bar to .../
foo*bar as well. However Apache logs show that the request was
received using %2A, and a 200 response was sent, not a redirect.

So it seems a bit of a mess.

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).

From RFC 3986:

  "The purpose of reserved characters is to provide a set of
delimiting
   characters that are distinguishable from other data within a URI.
   URIs that differ in the replacement of a reserved character with
its
   corresponding percent-encoded octet are not equivalent.  Percent-
   encoding a reserved character, or decoding a percent-encoded octet
   that corresponds to a reserved character, will change how the URI
is
   interpreted by most applications."

Or consider this:

helpers do
  def build_path(*path_components)
    path_components.map { |c| escape(c) }.join("/")
  end

  # If the path has already been decoded, we cannot
  # implement the inverse function accurately:
  def split_path(path)
    path.split("/").map { |c| unescape(c) }
  end
end

PATH_INFO comes from the CGI spec, and it says it should be decoded.

It also says a server MAY reject a request as invalid that has URL
encoded '/' characters, because (as you point out), it causes loss of
information.

   The server MAY
   impose restrictions and limitations on what values it permits for
   PATH_INFO, and MAY reject the request with an error if it encounters
   any values considered objectionable.  That MAY include any requests
   that would result in an encoded "/" being decoded into PATH_INFO, as
   this might represent a loss of information to the script.

   - http://www.ietf.org/rfc/rfc3875.txt, section 4.1.5

Maybe the PATH_INFO should obey the CGI spec, but there should be a
rack-specific env variable ("rack.path_info") that either doesn't
url-decode the path?

Might be worth looking at wsapi to see what they do, probably a wealth
of experience there.

But let's reconsider the CGI definition, given that we are talking
only about the PATH_INFO portion. RFC 3986 allows non-reserved
characters to be unescaped. Also, the definition of path in section
3.3 allows sub-delims and : and @ to appear unencoded.

So the only characters which cannot appear unencoded are / ? # [ ]

The server will already have dealt with ? and # by trimming off the
query string and anchor.

As for [ and ]

  "A host identified by an Internet Protocol literal address, version
6
   [RFC3513] or later, is distinguished by enclosing the IP literal
   within square brackets ("[" and "]").  This is the only place where
   square bracket characters are allowed in the URI syntax."

So actually, it's safe to unencode everything *except* %2F. This could
be achieved by:

  path.split(/%2F/i).map { |p| unencode(p) }.join("%2F")

Also, how would you reconstruct the original URL from such a
"partially encoded" PATH_INFO? This would break:

http://www.python.org/dev/peps/pep-0333/#url-reconstruction

If rack just follows the CGI spec for CGI vars, and tries to present
the original undecoded data elsewhere we have standard conformance and
non-loss of data.

I totally sympathize with your goal of making the rack spec allow
stuff you can theoretically do with HTTP, but I don't think partially
encoded PATH_INFO will really help.

The app I'm working on relies on URL reconstruction. It also would
benefit very much from being able to use a full URL as a
path-component... but even though HTTP's escaping rules would allow
that, its pretty clear that it's chance of working with actually
deployed code is low.

I wanted to do:

  http://example.com/ics/http:%2f%2fsome.site.com%2fcalendars%2fevents....

But since I will never (famous last words) have more than a single URL
in my path, anyway, I just dump it after the ? as the query info,
which works fine:

  http://example.com/ics/atom?http://some.site.com/calendars/events.ics

And ends up easier to construct, anyway.

This, btw, is how I found that the query info was being inject into
the ARGV... I was getting server 500 errors and rackup complaining
that "http://some.site.com/calendars/events.ics" was not a valid
configuration, because it was ARGV[0], and rackup was trying to open
it as a config file.

Aside: since this is Ruby we're talking about, we're not limited to
just strings. For example, PATH_INFO could be defined to be an array
of path components. Probably doesn't make life easier for anyone
though, compared with just having the original path available.

Regards,

Apache Couchdb <http://couchdb.apache.org/> provides a HTTP API. The
first component of the path is the database name. You are allowed to
specify a database name which includes slashes, but they must be
encoded as %2F. e.g.

  http://127.0.0.1:5984/dev%2Fcustomers/...etc

If you do this, then it places the database file on disk under a
subdirectory hierarchy matching the database name, e.g.

I clarified the SPEC accordingly.