gnu-linux-libre
[Top][All Lists]
Advanced

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

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)


From: bill-auger
Subject: Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
Date: Fri, 26 Jan 2018 00:49:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 01/25/2018 01:28 PM, Ivan Zaigralin wrote:
> To clarify, I agree with you and Luke down below that www subdomain is nice 
> and useful. It's only the tacit assumption that www.whatever.com = 
> whatever.com that I find annoying :)
> 

you quoted me but i also suggested that it is inappropriate to assume
that every client asking for 'foo.com' should always get a World Wide
Web server - not even when that client is a web browser - imagine some
'FooNet' IRC server accessible via irc.foo.com - there may very well be
no website associated with that IRC network - so what should a web
browser see when they enter foo.com or www.foo.com - the answer is
nothing because there is no server responding to those URLs and there
does not need to be - not only are those 2 URLs not equivalent, but
there is no reason to assume that either of them will (or *should*)
respond to any request from any client

i wll mention this next bit for completeness, only because no one else
has yet; though luke alluded to it (lest this thread go irreversibly off
topic) - that 'URL' stands for "universal resource locater" and 'URI'
stands for "universal resource identifier" - that very plainly means
that they are intended to refer to or identify, unambiguously, the
single canonical location of a single definitive resource (such as a
text file or photo) - it was even imagined that this could avoid
duplicate instances of identical files across the world (i.e.
jquery.min.js would have one and only one canonical URL and any URL
referring to a "copy" could collapse into an alias for or be verified as
a faithful duplicate of the canonical published copy hosted by it's
publisher) - as luke said, a file-system directory was not conceived as
such a definitive resources and the index.html convention was added as a
convenience - but it is just a convention and does not imply that there
should be any resource waiting for retrieval at foo.com/index.html or
any other of the infinitely possible URLs, unless it refers explicitly
to some known published resource

of course the URL and HTTP abstractions are abused almost beyond
recognition today aside from servers that still serve only flat files;
and arguably RESTful resource schemas - many web developers would be
quite happy if javascript were the only programming language and their
website had only a single entry point into a javascript "app" that did
all of it's arbitrarily complex business, perhaps even providing
services that generally run on dedicated servers (such as chat, file
transfer, and email), while conspiring with any number of external
servers (perhaps even refusing to serve you unless some external
3rd-party "partner" approves or unless your browser executes all of
provided scripts without fail, scripts often served by a 3rd-party); all
without ever changing the URL

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]