At 1:32 pm +0200 28/9/98, Patrik Faltstrom wrote:
>> At 8:25 am +0200 26/9/98, Keith Moore wrote:
>> >> - Packet and request hijacking is A Really Evil Thing. So, one goal
>> >> is the design of protocol and mechanisms for getting clients to
>> >> discover this additional structure and use it. It can be as simple
>> >> as discovering an enterprise's egress proxy to discovering Keith's
>> >> "oracle".
>>
>> I think the first statement needs more clarification. I think it is
>> reasonable to guess that most users, when clicking to download a piece of
>> software (for example) would not care if it came from a nearby cache. (In
>> fact, if it were a 15M update of Explorer or suchlike, they might be very
>> happy to discover a closer, faster option).
>
>What Keith wrote was that packet hijacking is bad. That doesn't mean
>that one should not redirect the user to a closer copy if possible, but
>that is something completely different than hijacking!
[NB: It wasn't Keith but Scott and he did also include "request hijacking"
which is what I am referring to.]
>Selection of 'closest copy of service' for any protocol _have_ to be part
>of the protocol itself, and not something that is solved on the IP-level.
Agreed. The answer probably lies somewhere within the URI domain but
perhaps if the re-direction is made more explicit - a message telling the
user they have been re-directed to the nearest copy - or a small item in
the corner of their browser showing this to be a cached copy rather than
the original... I guess what Keith and others are objecting to is not so
much the re-direction per-se but the lack of explicit consent from the user
- right? I am not proposing this as a final solution - far from it - but
the added value of user education that a resource may not (necessarily) be
uniquely defined by a single URL might help URI deployment in the longer
term...
...and, of course, this does not go for all cached objects but only that
subset which are regularly mirrored at sites remote from the source.
John
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST