[cgiapp] Re: CGI::Application::Dispatch: Apache vs. IIS

[Mark Stosberg]

On Thu, 18 Dec 2008 13:08:50 -0600
"Jason A. Crome" <cromedome at gmail.com> 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