[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

What about virtual hosting facility?



Hi list.

I'd like to work on the "Enabling virtual hosting facilities" section in
our policy draft.

I'd like to start the discussion on the basis of a bug submitted against
bugzilla: 
  
    309227 - webpath makes bugzilla not work when using virtual hosting

The bug submitter complains about the fact that the webapp comes as a
standalone web site and uses an url prefix like '/bugzilla' for every
static urls needed (link to css pages or images).

This works pretty fine for a common website structure but is definitely
a problem for virtual hosting.

What should we do in such circumstances?

Should the webapp provide a way to enable/disable the standalone state?

I'm thinking at a global webapps-common debconf question: "Do you want
this webapp to be standalone" (with a default answer to yes).

This could be a way to work around such bugs, asking the user which kind
of installation he wants:

    1 - standalone: we install stuff as usual and register the webapp
    with the webserver under a path like http://$host/$package/

    2 - virtual host: we install stuff as usual and register the webapp
    with the webserver as something like http://$package.$host/ (this
    means probably hacking some stuff in the webapp code where some url
    are made)

As you can see, this is deeply bound to the dh_webapps things that can
register web application with the webserver.

I'm also wondering what is the best severity for bugs like "Your foo
webapp package does not provide any Virtual Hosting facility".

Note that the bugzilla's one is currently marked as 'important'.

Thanks to your feedback, I'll start writing this section in our
policy.

Thanks.
-- 
                                  Alexis Sukrieh <sukria@sukria.net>
                                               http://www.sukria.net

« Quidquid latine dictum sit, altum sonatur. » 
Whatever is said in Latin sounds profound.



Reply to: