W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021


From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 3 Nov 2021 10:05:31 -0700
Message-ID: <CAPDSy+4HieUnkqKpiRUxghoHwFiR9=T8qGCXUH6dGg8Ge+aLdA@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Nov 2, 2021 at 8:38 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Wed, Nov 3, 2021, at 12:03, David Schinazi wrote:
> > I'm not sure it's really possible to solve the "as a client I want to
> > know all the feature set of this server" because the first intermediary
> > might know what all its backends support.
> That's a nice philosophy.  That seems like the cleanest outcome.  However,
> it doesn't give me an answer to the dilemma from before:
> > That means that there are cases where the connection supports the
> ability to negotiate :protocols in general, the resource supports this
> specific :protocol, and the combination of the two doesn't.
> I'm aware of cases where this happens already and we jump through all
> sorts of hoops as a result.  Are you suggesting that we just live with this
> situation because it is unavoidable?

One potential solution to this dilemma is to find a way to communicate to
the client what is supported (e.g. settings as you mentioned). Another
solution would be to have the client try and have a way to communicate the
reason for failure. There's discussion of a new status code in this thread,
and I like that. In general I much prefer the "try what you want to do and
failover if you fail" approach over the "ask for permission first" approach
because the latter introduces time-to-check-to-time-of-use issues.

Received on Wednesday, 3 November 2021 17:05:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 3 November 2021 17:05:57 UTC