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

Hi Kazuho,

On Thu, Nov 02, 2017 at 02:18:23PM +0900, Kazuho Oku wrote:
> >> IMO, we need to at least have a representation that can carry the size
> >> of the file, which cannot always be represented as a i32 value. So the
> >> introduction of a sized type (i.e. i32, i64) means that we would need
> >> to have _two_ decoders for numbers, instead of one.
> >>
> >> My question here is what the merit of having two decoders is.
> >
> > If you need to support integers of such large size, I think we're already talking about two decoders, because we need to support floats too.
> 
> I can understand your point that we would be having at least two
> parsers, one for integers and one for floats (or three, if we consider
> positive and negative integers as different types). But still, I am
> not sure if the fact justifies having multiple parsers for different
> sizes of integer types, since, as I stated, I do not see if there
> would be any practical merit (e.g., interoperability improvement).

In fact I think the root cause of the problem is that we must consider
the failure to parse as something normal, and not something which never
happens. Ie: a 32-bit content-length can be perfectly fine for many use
cases (probably 99.99%), but what is not acceptable is that the parser
silently fails to parse larger values and wraps or returns -1 or such a
thing.

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.

Personally I don't care if "q=0.33333" is rounded down to "q=0.25" or up
to "q=0.5" by an implementation which uses fixed floats with only 1 or 2
decimal bits, if that suits their needs. But integers must always be exact.

That's why I think that variable-length encoding can help (in fact ASCII
encoding actually *is* variable length encoding, just a very inefficient
format). All implementations can be compatible with their target use cases
without having to deal with difficult types.

(...)
> For floats, first let me state that I do not know if we even need to
> support it. To me it seems worth considering to drop it, as PHK
> suggested.

+1. We can define that "q=" is specified in thousands for example and
that only 3 decimals have to be parsed there.

Willy

Received on Thursday, 2 November 2017 05:55:29 UTC