Bug#32263: Splitting CGI-BIN
> Brian> What is the next step in moving this in to being official
> Brian> policy? I was told I couldn't request any changes to the
> Brian> various webservers until it was accepted as such.
>
> Quite the contrary. Policy documents current, working
> solutions. We should not make policy experimental solutions that may
> need to be backed out, or radically changed; policy needs to be
> fairly conservative, I think. The first step is to make sure that the
> web servers implement the script dir alias; while maintaining
> compatibility, and _then_ we make the _recommendation_ that packages
> switch over. We can't make the recommendation in advance of it
> actually working. And, then, at some point in the future, we cna make
> the new way of doing things mandatory.
When I first started this some 3 years ago (<sigh>), the web-server
maintainers refused to change their packages without a previous change
to the official policy.
Once it becomes official policy, then I can get them to make the
necessary changes. And once the webservers begin to change over,
then I can get the packages to change.
> I would also suggest that <webroot>/cgi-bin and
> <webroot>/cgi-lib not point to the same place on the file system,
> since there is no reduction of name space polluction until the flag
> day when they shall point to different dirs; and that would not be
> possible to effect a gradual transition (day F: all packages refer to
> <webroot>/cgi-lib, but place files in the location of
> <webroot>/cgi-bin; when the web servers update the script aliases to
> point to new dir; every one of those packages break. This plan also
> needs the users to all have started using cgi-lib for _some_ cgi
> scripts (debian provided) but not others (locally provided) -- seems
> quite confusing, unless care is taken to handle this.
<webroot>/cgi-bin should default to "~www-data/cgi-bin". However,
existing implementations should not be automatically changed so as not
to break anything. Once all packages follow the new policy, then they
can do semi-automatic changes to the /cgi-bin setting.
The reason no webserver must do a behind-the-scenes changes is that the
webmasters of some existing implementations will have started inserting
CGIs in the existing place and we should be careful not to break that.
Done carefully, there will be no breaking. Packages currently place files
under "/usr/lib/cgi-bin/*" and references them as "/cgi-bin/*". This works
because webservers map "/cgi-bin/" to "/usr/lib/cgi-bin/".
Webservers need to create a standard alias for "/cgi-lib" to "/usr/lib/cgi-bin".
Once done, installed scripts will be available via both "/cgi-bin/script"
and "/cgi-lib/script". The packages then change all of their webspace
references to be "/cgi-lib/script". However, both before they make that
change and after it is done, there is no interruption of service.
Once all the packages have changed over, then webmasters can start using
the "/cgi-bin/" alias for what it was intended: local CGI programs.
If you can see a problem with this, please let me know. It's been presented
before and everybody seemed happy with it.
Brian
( bcwhite@precidia.com )
-------------------------------------------------------------------------------
Do, or do not. There is no "try". -- Yoda
Reply to: