Update inets from RFC2616 to RFC7230?

[Jesper Louis Andersen]

On Wed, Oct 21, 2020 at 3:18 AM Gulyás Attila <toraritte@REDACTED> wrote:

> With  my  minimal  HTTP experience,  I  was  somehow
> under  the   impression  that   RFC723x  conformance
> would  provide extra  benefit.
>

It does, though subtly not the way one would expect. It is mostly there for
future implementers of HTTP clients and servers, so they don't have to
first look at the old specification and then go on a hunt for how different
implementations handle all the parts which aren't codified precisely. The
goal of the new specs were not to define a "new set of rules" but rather to
codify "most people solved that problem by doing this". If you did well on
the old spec, chances are you are also compliant with the new spec, because
that is how it has been written in the first place.

Also note there is room for interpretation in most specifications. While
there is a sensible thing to do, it isn't guaranteed everyone will do it.
For instance, the specs, both of them, generally argue you should not have
a body on a GET request (background: it tends to break caching and
proxying, so it is defined to be ignored); yet ElasticSearch is somewhat
famous for having done exactly that. The body contains the request and
thus, it has semantics, violating the specification, strictly speaking. But
ElasticSearch is still popular...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201022/0b527641/attachment.htm>