Re: New Version Notification for draft-nottingham-structured-headers-00.txt

Hi Kazuho,

On Thu, Nov 02, 2017 at 04:58:57PM +0900, Kazuho Oku wrote:
> > Thus I'd rather suggest that number parsers MUST be able to correctly
> > parse all sizes supported by the implementation AND detect their own
> > failures to do so.
> 
> I think that this is a powerful argument.
> 
> To rephrase it my way, the question is if (and how) we can expect
> interoperability improvement by limiting the maximum of a integer
> value. Unless there is a reason, we should not have limits.
> 
> As you have stated, each endpoint will have their own limits, and they
> would not be able to handle values above that. So I basically agree
> with you that having a limit does not improve interoperability, while
> making things complicated.

Yep!

> The only case I could expect an improvement by having a hard limit is
> when an intermediary is involved.

It can seem to be the case but in practice, intermediaries just have to
adapt to realistic use cases as well, because in their position, having
to consider performance is critically important as well. For example I
don't intend to change the 32-bit chunk parser in haproxy for a while
as it will severely hurt performance on 32-bit platforms. It will only
change the day I start to receive a bug report about it being too small.

> Consider the case in which we have a proxy that can only handle
> integer values under 2^32. The proxy rejects forwarding messages with
> a greater integer value included at any place within the message,
> regardless of if it is actually using the value.
>
> If we had limited the maximum to 2^32-1, the client and the server
> trying to communicate a value greater than 2^32-1 will be forced to
> use something other than an integer type. At the cost of complexity,
> the two would be possible to communicate with each other through the
> proxy.
> 
> But if we have no limits, the two will encode values greater than
> 2^32-1 as integers, and the proxy will refuse to forward the message.

Yes but in practice intermediaries are progressively exposed to changes
so it's really not a problem to deal with this. So this problem basically
happens a few times in a decade and is quickly addressed after someone
says "bah what a crappy code still using 32-bit when everyone is running
64" and then the implementer thinks it's the right time to switch.

> Fortunately, I think that the problem can be made a non-issue by
> clarifying that intermediaries must not refuse to forward messages
> when it finds an integer value greater than it can parse in a header
> field attribute that it does not use.

I'd reformulate differently : as long as whatever it manipulates will not
affect the message's integrity nor subsequent messages' integrity, it can
simply pass as-is. Haproxy doesn't try to parse header fields it doesn't
use (the name, colon, value and CRLF are indexed but that's all). But
definitely content-length is critical to the message's integrity and the
next ones'. Similarly if it needs to rewrite a header field value based on
a previous value, it's important that the value is not truncated during
conversion (which is why our internal integers for application-level
processing are 64-bit, such processing is not performance critical).

> What do you think about adding such a requirement?

I think I'm fine with this.

Willy

Received on Thursday, 2 November 2017 08:14:48 UTC