Re: I-D for a YANG data model to configure HTTP clients and servers

[Kent Watsen <[e-mail]>]

[Top-posting for convenience]


Hi Willy (and Mark!)

Based on yours and Mark's comments, I plan to remove the "protocol-version" field from the "ietf-http-server" YANG module.   As you say, it's seldomly used and, if ever needed, implementations of the "ietf-http-server" YANG module can "augment" (a YANG term) it back in.

Any other comments on draft-ietf-netconf-http-client-server?

Thanks!
Kent


> On May 11, 2020, at 11:44 PM, Willy Tarreau <[e-mail]> wrote:
> 
> Hi Kent,
> 
> On Mon, May 11, 2020 at 06:57:23PM +0000, Kent Watsen wrote:
>>> Regarding the http-server-grouping - I'm not sure I understand why it's
>>> important to configure the version that the server supports. Wouldn't a
>>> server just support all of the versions it implements?
>> 
>> Maybe.  But my understanding is that older/newer HTTP versions are purposely
>> disabled sometimes for application-level compatibility reasons.  By
>> "application", it may not necessarily be a standard web content server (i.e.,
>> it might be an application that uses a REST-based API).
> 
> As a server-side reverse-proxy developer, I don't think I've ever heard
> of a single case where an application required not to use a certain
> version due to compatibility issue. Furthermore, applications designed
> to work over HTTP/1.1 work pretty fine when the reverse-proxy speaks h2
> with the client, and the application doesn't even know, so I'd say this
> is totally transparent to the application. The only known interoperability
> situation we've found is some rare servers still matching some header
> fields in a case-sensitive way, and failing to see them when these
> headers come from h2. But this is so rare that a year ago we've switched
> everything to lowercase (even HTTP/1) and received extremely few issue
> reports (probably a handful among tens to hundreds of thousands of
> deployments).
> 
>> FWIW, the NGINX server configuration file has an "http2" flag in its "listen"
>> directive, and Apache's "Protocols" directive takes values like "h2" and
>> "http/1.1".    To be fair, these directives may only exist to introduce
>> support for new protocol versions (e.g., HTTP/2) in a backwards-compatible
>> manner. 
> 
> That's it, and also because the new protocols usually introduce new bugs
> that you don't want to expose users to. In haproxy we used to require an
> explicit declaration for the first two years, then we've simplified the
> configuration and enabled h2 by default, then we recently got caught by a
> vulnerability in our implementation, and figured it was so well integrated
> that we couldn't disable it anymore! We may reintroduce a tunable for this
> but quite frankly, disabling a standard protocol is similar to thinking
> about explicitly disabling HTTP/1.1: nobody would find this wise nowadays.
> 
> Just my two cents,
> Willy