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

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

Received on Tuesday, 12 May 2020 03:45:04 UTC