On Thu, 18 Dec 2008 13:08:50 -0600 "Jason A. Crome" <[email protected]> wrote:
> To save you all a bunch of frustration and time, please be aware of > the following subtle distinction between PATH_INFO on IIS and Apache: > > Consider this URL: http://yourserver/myscript.pl/foo/bar > > On Apache, PATH_INFO will be set to /foo/bar. On IIS, PATH_INFO is / > myscript.pl/foo/bar. This subtle difference causes > CGI::Application::Dispatch to be non-functional in CGI mode on IIS > (tested versions 6 and 7). Maybe you all know this already, and I am > a day late and a dollar short (as usual). But in case you don't, I > hope you find this helpful. I looked around to see how other tools were handling this. Here's what I found: - CGI.pm used to have an explicit comment about working around IIS's brokeness in it's path_info() method. I'm not sure how CGI::path_info() works on IIS these days. I don't want to tie C::A::Dispatch to CGI.pm in any case. - Catalyst and HTTPx:Dispatcher both use URI.pm, which uses URI::http or URI::https, which inherits from URI::_server, which inherits from URI::_generic. I assume Catalyst works on IIS, but I'm not sure I want to pull in 3 or 4 URI modules if they only serve a single small workaround. - Mojo implements it's own PATH_INFO handling, using an array of packages Mojo::Message, Mojo::Message::Request, Mojo::URL, Mojo::Path and Mojo::Bytestream. I'm not sure how it fares on IIS. In summary, I think your idea is reasonable: you'll contribute and maintain a IIS subclass, which we'll incorporate and release in the main distribution. Mark -- http://mark.stosberg.com/blog ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
