Re: [Technical Errata Reported] RFC7230 (4667)

[Willy Tarreau <[e-mail]>]

On Thu, Apr 14, 2016 at 06:50:43PM -0600, Alex Rousskov wrote:
> On 04/14/2016 04:39 PM, Roy T. Fielding wrote:
> 
> > Don't confuse the various lenient ways in which implementations parse
> > HTTP with the requirements on generating HTTP messages that are
> > defined by the ABNF. The ABNF is intended to be more restrictive.
> 
> I fully agree, but we are not discussing ABNF creation IMO. We are
> discussing a syntax change by an HTTPbis RFC. To change HTTP/1 syntax
> that has been in use for many years, the "Founders Intent" alone is not
> enough IMHO. There must be other compelling reasons. The only other
> reason given so far was "lack of known examples", followed by your
> discussion of "space padding" as a known usage example. I expect the bar
> for HTTP/1 syntax change to be significantly higher.

Alex, it's not that black or white. We focused on maximized interoperability,
so you need to understand that when some people report that product X,Y or Z
doesn't even support chunk extensions, that other products are simply broken
regarding this and we realize that nobody produces them, it's natural to
deprecate them. They were apparently re-added in a stricter way based on
identified implementations to optimize the intersection between producers
and consumers.

It's very difficult to satisfy every implementation, especially with HTTP
that everyone tried to implement without looking at the doc in the late
1990 and early 2000 resulting in many incompatible implementations.

So here there's no intent to break anything, instead there's an intent to
make everything work together based on all the data everyone could collect.
It's not rocket science but it proved to work pretty well given all the
interoperability issues that could be addressed (eg: header folding,
multiple content-length, CRLF after body, etc).

I do think that adding the BWS back could be enough. And maybe even adding
the only one ICAP uses. After all it already took something like 5 years
for someone to notice this change, maybe ICAP is the only exception to the
rule and is sufficient to address without further breaking existing
implementations.

> > And, no, it is NEVER a good idea for new IETF protocols to
> > effectively alias other IETF protocols.
> 
> AFAICT, ICAP does not alias HTTP. It uses RFC 2616 to define HTTP
> messages. This is similar to RFC 7230 using URI definitions from RFC
> 3986. When URIbis obsoletes RFC 3986, I expect the authors to be very
> careful not to accidentally invalidate HTTP/1 messages. IMHO, HTTPbis
> should offer the same courtesy to ICAP.

Not exactly in fact, RFC3507 says this :

   ICAP is a request/response protocol similar in semantics and usage to
   HTTP/1.1 [4].  Despite the similarity, ICAP is not HTTP, nor is it an
   application protocol that runs over HTTP. (...) ICAP uses TCP/IP as a
   transport protocol.

So in short it allows implementers to save time by reusing their HTTP
parsers but does not expect to be strictly compatible. There are even
some intended differences, such as :

   Note in particular that the "Transfer-Encoding" option is not
   allowed. (...) Encapsulated bodies MUST be transferred using the
   "chunked" transfer-coding described in Section 3.6.1 of [4].
   However, encapsulated headers MUST NOT be chunked.

These ones alone prevent reliable forwarding over HTTP gateways. But I
do agree that if we don't break anything by adding the BWS back it
would be better, at least because we're now pretty sure that people
who need to adapt their HTTP parsers to also support ICAP will support
it anyway.

Regards,
Willy