The new /etc/javascript-common/javascript-common.conf with the Alias pathway
for /javascript overrides any virtual hosted development configs having
their own /javascript pathway.

I have a simple solution: Since these are all javascript libraries make
the configuration /javascriptlibs and this eliminates this issue.

I have roughly 10 sites with their own /javascript reference paths. I
just changed the Alias under javascript-common.conf to that
/javascriptlibs

It may be a few more characters but it's a simple solution and
references globally available Javascript Libraries separate from one's
own private javascript files and libraries.

Hi,

  Thanks for the report.

  (I've reassigned this bug to the 'javascript-common' package
 which is the one which actually makes the global /javascript/
 alias.)

  You raise an interesting point here.  The /javascript/ alias
 could indeed be used by people who wish to use the jquery package,
 and if that is the case then there will be breakage.

  There are two possible solutions to this bug:

  1.  Do nothing.  Rely upon the end user (you in this case) to
     remove the global alias, and change it to their own if they
     spot the collision.

  2.  Change the default for the javascript-common.  I'd actually
     suggest we use /javascript-common/ as the alias, rather than
     your suggestion of '/javascriptlibs'.  That matches the package
     name, if not the directory.

  I've no strong preference on the way forward here, but I'd slightly
 lean towards the first option.  I can see that it could cause users
 pain though; so the second would be acceptible.  I just fear that
 whatever "new name" we pick for the alias will be taken by *somebody*.

  So its the lesser of two evils:  Leave as-is, so that people using
 the package already don't get suprised, or change it and still run
 the risk of a collisions - and a new bug report from a different
 user..

Steve

Your solution for javascript-common works for me and maintains
nomenclature.

- Marc

Marc J. Driftmeyer
mjd@reanimality.com
http://www.reanimality.com
(509)435-5212

We have a large number of virtual servers with javascript files rooted
to "/javascript".

The /etc/javascript-common/javascript-common.conf file overrode all of
those configurations when the server was restarted. It took a little
while to work out what the problem was.

I'd like to suggest that such a configuration change should be made more
visible to the person upgrading the system and should provide a choice
about whether or not is should be enabled.

Thanks
Rory

Hi

this bug is open for more than two years I still don't see clarification
why this needs to be done.

I see two major issues with this:

1. The alias is made globally for all (virtual) hosts, what just breaks
   lot of applications silently.

2. The /etc/lighttpd/conf-available/90-javascript-alias.conf symlink is
   unconditionally recreated on each package update.

Given that 1 breaks unrelated software (this is actually how I came into
it) and 2 is violation of policy 10.7.3, I am upgrading this bug to
serious.

clone 474913 -1
retitle 474913 javascript-common overrides /javascript globally in apache2
retitle -1 javascript-common overrides /javascript globally in lighttpd
notfound -1 5
thanks

Excerpt from /usr/share/doc/apache2.2-common/README.Debian.gz:

    If the local administrator is not comfortable with packages
    activating their config files by default, it is possible
    to change the 'Include /etc/apache2/conf.d/' in apache2.conf
    into 'Include /etc/apache2/conf.d.enabled/' and create that
    directory. He can then put symlinks to the files in conf.d
    which he wants to enable into conf.d.enabled.


Given this bug:
 - has a workaround as suggested above
 - is the same as #565738 and #604980
 - could apply to many other packages (nagios, gitweb, doc-central, etc)
 - should probably get fixed in apache itself (#605227)
 - is a release blocker

I suggest its severity should get lowered.

Furthermore, I'm splitting this bug in:
 - javascript-common overrides /javascript globally in apache2
 - javascript-common overrides /javascript globally in lighttpd

The latter only being in javascript-common/8, it doesn't affect squeeze and
therefore shouldn't be listed in squeeze release blockers.

Many thanks !

----- Original message -----

I would also highlight that "fixing" this would in
fact break many other packages that are expecting
the global alias. I don't think it would be a good
idea to change the current behavior, especially so
close to the release!

Thomas Goirand (zigo)

I totally agree with Michal Čihař, and this bug report should have been
issued by (at least) changing /javascript to something less risky before
releasing. I think even /javascript-common is much too common (sic) to think
it'll not break a few websites. A company could use /javascript for its
websites and have a /javascript-common for common javascript on all of its
websites and thus be inconvenienced.

For the record : I've just tried to install rsslounge on an apache server,
and the website was not working *at all*. The diagnosis was a bit tricky,
there was no error in the server logfiles because of the local rewrites by
rsslounge... In fact it was trying to access rsslounge's javascript in
/usr/share/javascript-common/, where obviously the files were not available.

I can see the point of this package, but I find it too intrusive. In fact, I
find global Aliases too intrusive and I think they should never be defined
for a whole server, but always on a per-vhost basis. We rarely need all
aliases to be on all of our vhosts and sometimes it's a (small, I concede)
security inconvenience.

Here's what I suggest :
- use /javascript-common-libs instead of /javascript and propagate the name
change to the dependent packages. The name javascript-common-libs contains
the package name and is not too common
- javascript-common package should behave like phpmyadmin and ask the user -
at install time - which web servers he'd like to automatically configure to
use it

Regards

severity 474913 normal
thanks


The /etc/lighttpd/conf-available/90-javascript-alias.conf symlink
is no more unconditionally recreated on each package update.

So, I'm downgrading severity from 'serious' to 'normal'.


Cheers,

Now that version 11 has hit testing (It only took over 1000 days),
and that javascript-common no longer rewrites the alias on every reconfigure
if the sysop disabled it, I don't see the point to separate apache2 bug from
lighttpd one.

The question is whether it is ok to use /javascript url namespace or not.

The choice of the http deamon is not relevant, imho.