Re: [Technical Errata Reported] RFC7230 (4667)

On Fri, Apr 15, 2016 at 10:19:40AM -0600, Alex Rousskov wrote:
> On 04/14/2016 10:49 PM, Willy Tarreau wrote:
> > 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.
> 
> I wonder which part of my argument you consider to be "black or white".

The way I read your comment makes me think you believe that there was
an intent to purposely break existing implementations, which has been
the opposite during all this work. It's not because some breakage results
from the change that this breakage was intended.

> > 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.
> 
> Agreed. However, we are not discussing deprecation (that did not happen)
> but the syntax change (that did). Those two issues are completely
> different IMO.

A lot of things have been enforced with the new spec, based on the feedback
gathered. For example the HTTP-version has now become one digit dot one digit.

> > They were apparently re-added in a stricter way based on
> > identified implementations to optimize the intersection between producers
> > and consumers.
> 
> "Stricter way" does not automatically "optimize the intersection between
> producers and consumers". Please re-read the history summary by Roy: The
> WG removed whitespace because it was deemed "unnecessary", not because
> there were any known implementations that did not support whitespace.

"deemed unnecessary" happens after not finding any counter example. That
doesn't imply they don't exist. Conversely there were examples of
implementations that did not support extensions at all.

> There is a big difference between "removing something that does not
> break any known implementation" and "removing something that breaks
> known implementations".

Yes exactly and as long as no known implementation it found, you're
neither in any case. That's what I meant by "black or white". Here
it's simply removing something which is expected not to break any
implementation and which will make others more interoperable.

> I understand that the WG did not know about implementations using
> whitespace. However, using prior lack of knowledge to _justify_ leaving
> a mistake in a *bis RFC seems strange.

But how do you retro-document a protocol that has lived for 15 years
with everyone doing his own fork because he knows better, or not
implementing what is considered too difficult and useless, or even
makes different choices from others on grey areas resulting in possible
smuggling attacks for example ? At some point you have to decide this
causes trouble to a number of implementations and is apparently not used
by anybody, let's make it clearer.

> > I do think that adding the BWS back could be enough. And maybe even adding
> > the only one ICAP uses. 
> 
> The following two changes would be enough to cover _known_ use cases:
> 
>   1. BWS after ";" to accommodate the widely used ieof extension.
>   2. BWS after chunk-size to accommodate space padding.

OK.

> I am saddened by your audacity to use the "5 years" argument to prove
> correctness of a subtle syntax change in a *bis* RFC that was published
> less than 2 years ago and that is not even applicable the latest
> protocol version.

It's not audacity, it's just a fact. This change was made 5 years ago and
this problem is reported now. Like any bug, until nobody discovers it it
can live long. It simply confirms that if it took 5 years for the first
report of valid use case to come, there were *really* few implementations
relying on this and it is understandable they were not spotted. That's all
I'm saying.

> >>> 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.
> 
> IMO, the above RFC 3507 text matches what I said and does not imply any
> allowance for incompatibility with HTTP chunked encoding syntax. ICAP is
> not HTTP but ICAP message bodies use HTTP chunked encoding.

Not only the body, but the request line, response lines, headers an
delimitation between headers and body is made to work like HTTP.

> > 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. 
> 
> I am sorry, but I believe you misunderstand what ICAP is and, hence,
> misinterpret its specs.

No, I've used it 15 years ago. I've even seen some people use it over some
lenient HTTP gateways.

> ICAP does not use HTTP as transport and does not work with HTTP agents.
> ICAP uses HTTP chunked _encoding_ for sending HTTP message bodies over
> TCP connections between ICAP agents. The syntax change in HTTPbis breaks
> ICAP use of HTTP chunked encoding.

Absolutely. It's too bad it was not identified by then, but we can circle
in loops forever asking why is was not identified instead of proposing a
solution. Your proposal might be fine, and maybe in 2 years we'll get
another report for it not being enough and another errata will simply be
emitted. That's the purpose of erratas.

> > 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.
> 
> And we also know that HTTP agents use that whitespace for padding.

OK. I wasn't aware of this one.

Willy

Received on Friday, 15 April 2016 19:54:13 UTC