Am Monday, 22. September 2003 22:05, schrieb Robert Ferney: > I'm not going to pretend to know how things should work here.. > however I am assuming that if you use a > http://machine/path/filename.ext > to specify the results that you desire to include, that you are > expecting that the <machine> server will return filename.ext in the > format that it does normally, under the assumption that <machine> is > configured and operates properly. > > If this is true, then the case where the <machine> happens to be the > same as the one on which axkit is operating, then that same behavior > should hold.
Yes - if using http. My point is, that a resource usually has many URLs associated to it, and axkit is definitely not accessing resources via http. Every protocol has it's own retrieval semantics. We already are on the server side of the request - local access is local access, and follows different rules than network access via http, even if the machine involved is the same. For the browser, the resource seems to be "http://machine/file.ext";. The apache web server translates this request into a local identifier ($r->filename) during the translation phase, and for the local content handler, it is a file resource, not a http resource. Now, for convenience, axkit uses the apache name space (virtual file tree). The 100% correct and consistent solution would be to go where CGI and PHP and all other content handlers go, use direct file access without apache's path translation. It would be a highly consistent behaviour with other content handlers, but would render absolute paths near useless - hardcoding the document root is hardly a good idea. It is well-defined, logical and intentional that AxKit only uses providers to serve scheme-less URLs. Any other behaviour would be inconsistent. As a side note - an alternative to http://localhost/ to get at your CGIs would be to write a CGI provider which executes the given file as CGI. That's fairly easy to do, and shows how powerful the Provider mechanism is - it is a fair replacement for not having <insert-your-favourite-content-handler>. Via that route, you would even be able to include PHP (using the CGI executable). -- CU Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
