On Mon, Jan 13, 2003 at 06:46:19AM -0500, Rodent of Unusual Size wrote: > okey, here's anpther take on the %2f thing. as a reminder, we > currently reject any reques that includes an encoded slash in the > pat with a 404. this breaks environments which need to use %2f in > the path info. the issue has to do, in part, with decoding the > %2fs into slashes, and possibly having to re-encode them again. > > i've been fighting with saving %2f state and restoring it for a long > time, but to no definitely acceptable conclusion. but last week a > possible alternative came to mind: if the AllowEncodedSlashes directive > is set to 'on', unencode everything *except* %2f. then let it go > through the normal processing. if %2f is part of the path, the > request will fail with a 404 anyway when the document isn't found; > if the %2f is strictly in the path-info, it won't intefere with > document location and will be available to the resource as expected. > > i have a patch for this against 2.1 that i'd like to send, but i > won't bother if people are going to veto all over it without even > looking at it.
That sounds rather hacky. IMO, Apache should not do any URI decoding. Instead, Apache should figure out who is going to handle the request (i.e. map the identified resource to a handler), then let the handler do whatever processing is appropriate on the URI. Today, Apache unconditionally decodes the URI (see the problems that Mike Pilato just posted about today), which really horks systems that need to pass that URI further along (e.g. proxy-like code). If Apache is going to decode the URI, then it should first split the URI into path segments (an array) and then perform the decoding. Thus, you can make http://host/path/foo%2fbar/baz into ["path", "foo/bar", "baz"]. You can then encode each piece, and join them together with "/". But again: URI munging should be left to handlers rather than the core. (altho, of course, the core can provide utilities to those handlers) Cheers, -g -- Greg Stein, http://www.lyra.org/
