RE: multi-host virtual sites for HTTP 1.2

If you're not convinced that you want that large a (virtual) site, OK by
me. But I liked your other reasons for referrals, too:

[Roy said:]
	There are good reasons to support a
	URI rewriting mechanism on the client side (e.g., to make the URI
	syntax truly extensible, support automated mirroring, support URNs,
	etc.), but I haven't considered single-site performance to be one
	of them.

Administrative flexibility and distributed sites were also mentioned as
other good uses.

More comments below.

>----------
>From: 	Roy T. Fielding[SMTP:fielding@liege.ICS.UCI.EDU]
>Subject: 	Re: multi-host virtual sites for HTTP 1.2 
>
>Well, I still don't like it -- I see no reason for such a huge site
>to be located behind a single DNS name.  The top URLs can be on the
>main site (or just redirections from that site) with all other
>references relative from there.  I don't see why HTTP needs to 
>replicate the work of DNS.

It doesn't. It is applying the same principles used by DNS to the part
of the HTTP URL that DNS doesn't own, for the same reasons as DNS uses
them in its part of the URL.
>
>In any case, please be sure to make the syntax parsable
>
>>>	Referral	= "Referral" ":" prefix 1#referral-URI
>>>	prefix  	= absoluteURI
>>>	referral-URI	= absoluteURI
>
>can't be parsed because "," is valid in absoluteURI.  In other words,
>you need to use <> or "" as delimiters.

OK. Thanks for pointing it out.
>
>Finding a way to do it with multiple Link header fields would be better.

So, would you suggest something like:
	Link: Referral <absolute-URI-1>
	Link: Referral <absolute-URI-2>
	...

And why do you like it better? It seems weird to me, but in the way that
sometimes says to me that it's because my intuition hasn't been trained
properly yet.

Paul

Received on Thursday, 11 July 1996 12:06:04 UTC