[PLUG-Devel] url preference - a matter of syntax (?)

Ed plug at 0x1b.com
Sun Oct 23 01:13:20 MST 2011


On Sat, Oct 22, 2011 at 10:14 PM, Eric Shubert <ejs at shubes.net> wrote:
> A question came up today at the (server) InstallFest, which I'd like to
> consult the community about.
>
> When setting up a web site|service|thing, the "thing" can be specified as
> part of the URI authority, e.g. a subdomain (as in
> http://thing.domain.com/), or as part of the URI path (as in
> http://domain.com/thing/). The difference just depends on the web server
> configuration, AFAICT.
>
> Question is, which syntax/method is preferable, _and why_?
>
> Assume, for the sake of argument (if you must make any assumptions), that
> you have a Reverse Proxy server (NGINX for example) at your disposal, and
> there are several "things", some of which run on the RP server, and others
> which run on different machines|hosts (virtual or otherwise).
>
> TIA for your thoughts on this. Web links will suffice if you find relevant
> ones. I'm not quite sure what I'd google to find a relevant opinion.
>
> --
> -Eric 'shubes'
>

Three things come to mind:
1) The thing.domain.tld format is usually more manageable as it can be
done at the DNS  - you can pick VirtualHost vs SeparateServer vs
DifferentISP not to mention gracefully managing migrations, downtime
and volume spikes...etc

2) Fire-walling is also easier with this format and conflicting ports
just aren't a problem, especially for things like FTP. However having
a Handler (WebDAV PHP etc) run from a URI's root can limit one's
options - mixing handlers in the same URL directory can get messy.

3) Certificates can make the domain.tld/thing(s) easier to implement -
but there can only be one URL listed in the cert, unless you get a
wildcard cert for *.domain.tld style deployments. If you need to
separate thing1 from thing2, sharing a cert may not work all that
well.

Cool URIs is always a fun read - http://www.w3.org/TR/cooluris/   and
 http://www.webmonkey.com/2011/01/a-guide-to-designing-cool-urls/


More information about the PLUG-devel mailing list