W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Alternative Service Indication

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 2 May 2014 12:50:38 -0700
Message-ID: <CABkgnnWmv7BinoFa+gSgPkLyqAUYdbj+XFd20_d=wxzg65xGoA@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Erik Nygren <erik@nygren.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 2 May 2014 12:34, William Chan (陈智昌) <willchan@chromium.org> wrote:
> "4) allow it to report load properly associated with
> us-east-1.example.com, especially if other DNS names could have been used
> to reach it."
> I am not sure how to do this load attribution correctly if
> us-east-2.example.com might also be pointing to it, as pointed out as a
> possibility in Erik's email.

I'll confess that I didn't find that one especially compelling.  It's
nice to have, but I imagine that many of these cases are adequately
addressed by examining Host header fields.

The potential for looping seems like a more valid reason to *require*
the use of an indicator.

That is, if Server A and Server B are both alternatives, then it might
be perfectly valid to have them both offload onto each other.  But
that's usually something that you want to have happen on a longer time
scale.  As Erik notes, rapid bouncing back and forth could be a
problem.  I had assumed that clients would have to protect themselves
against bad servers doing this anyway [1].  I think that I'd prefer

The potential for tracking using this mechanism means that we need a
clear, strong reason for mandating a mechanism.  (The reason I created
the PR was to try to drive discussion to conclusion :)

[1] I need to create security considerations regarding this...
Received on Friday, 2 May 2014 19:51:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC