At 02:00 PM 9/25/2003, Jeff Trawick wrote: >Geoffrey Young wrote: > >>while I'm still new exactly how APR fits in the whole picture, maybe some of >>ap_core_translate belongs there, since what seems to be happening is that some OSs >>get tripped up on valid URIs (and 3.3 of RFC 2396 does seem to indicate that the URI >>presented is indeed valid). > >yes, the URI is indeed valid... however, core's translate name hook has to assume >the URI maps directly to a file on disk via DocumentRoot, and APR is able to tell us >(on Win32, Netware, etc.) that the resulting filename isn't valid...
The handler is going to have to run defense around one of the hooks, either translate_name, or map_to_storage, to prevent us from attempting to serve the file from the file system. r->proxyreq is also fatal, but mod_proxy does just that to prevent the file from being translated. But I suspect our real problem is that translate name shouldn't try to handle the file name... that the map_to_storage hook should. If we merge those two core handlers into the map_to_storage phase, do we sufficiently resolve the problem? As far as embedded colons, less than or greater than signs in the filename path, we need to come up with much more clever code to accept those. Perhaps we can cooerce the filepath functions to 'ignore' invalid filename parts in these merge operations with an APR_FILEPATH_ALLOW_INVALID argument. Then it's up to the dir_walk'er to merge in components, and allow such cruft once it is past the 'filename' part, into the PATH_INFO part. Bill
