Re: SETTINGS_ENABLE_CONNECT_PROTOCOL and new protocols

Dare I say that it sounds like we are reinventing RFC 2774[1]?

Section 7 defines the 510 Not Extended status code:

   The policy for accessing the resource has not been met in the
   request.  The server should send back all the information necessary
   for the client to issue an extended request. It is outside the scope
   of this specification to specify how the extensions inform the
   client.

   If the 510 response contains information about extensions that were
   not present in the initial request then the client MAY repeat the
   request if it has reason to believe it can fulfill the extension
   policy by modifying the request according to the information provided
   in the 510 response. Otherwise the client MAY present any entity
   included in the 510 response to the user, since that entity may
   include relevant diagnostic information.


[1] - https://datatracker.ietf.org/doc/html/rfc2774

On Wed, Nov 3, 2021 at 5:09 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

>
>
> 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.
>
> David
>