Re: [yapcom] Problems Hosting Yapcom on Linux/Apache 2.0.x

[prev] [thread] [next] [lurker] [Date index for 2003/11/24]

From: Shlomi Fish
Subject: Re: [yapcom] Problems Hosting Yapcom on Linux/Apache 2.0.x
Date: 19:04 on 24 Nov 2003
On Mon, 24 Nov 2003, Gabor Szabo wrote:

> On Mon, 24 Nov 2003, Shlomi Fish wrote:
> >
> > The problem turned out to be this: the CGI script file refused to serve
> > files out of the $YAPCOM/files sub-dir. I temporarily resolved it by
> > adding the following Apache Directive before the ScriptAliasMatch:
> >
> > <<<
> > # Configuration for Yapcom
> > Alias /yapcom/files /home/shlomi/progs/perl/yapcom/site/files/
> >
>
> strange as I think it does not need with my Apache bt I might have missed
> something I already configured.
>

Well, it does not work without it on my workstation here.

> >
> > Now: we can resolve it permenantly in several ways. One would be to add a
> > note in the README to add this directive to Apache. The other is to tweak
> > the CGI script to read and serve files out of this directory if their
> > prefix is right.
> >
> > The first method is faster as far as HTTP serving is concerned. The second
> > one is more user friendly. We can also do the second and recommend to add
> > the first, so we can make the best of both worlds.
> >
> > Let me know what path would you like to follow, and I'll send you a patch.
>
> patch the readme first.
>

OK.

> fixing the cgi script is actually already in the TODO list
> but what we'll do is use PATH_INFO and let the user configure the html
> pages under this script
>
> I think like this:
> ..../yapcom/yapc.pl/login.html
> ..../yapcom/img/
>
> of course then the user can put rename yapc.pl to be yapc and the she will
> have nicer paths:
>
> ..../yapcom/yapc/login.html
> ..../yapcom/img/
>

I'm sorry, but I find /yapcom/yapc a bit ugly. It reminds me of those
funky URLs generated by Zope or this URL to which Mark Veltzer's
homepage redirects:

http://www.veltzer.org/html/temp/html/projects/Website/main.html

Again, a lot of reduntant components that add nothing to the information.
A URL should be informative and reflect the mental structure of the site.

I suggest we keep the main pages  of the site at the root directory, while
using the img and/or files sub-directory for files. All this discussion is
void if every path can be configurable.

Regards,

	Shlomi Fish

>
> Gabor
>



----------------------------------------------------------------------
Shlomi Fish        shlomif@xxxx.xxxxxxxx.xx.xx
Home Page:         http://t2.technion.ac.il/~shlomif/

An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.

	Falk Fish
There's stuff above here

Generated at 20:06 on 24 Nov 2003 by mariachi 0.51