W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: Structured Fields / Retrofit: Fixing up parsing (#2235)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 27 Feb 2023 14:20:07 +0100
Message-ID: <0fb55813-0e07-3002-99db-7124dbb63872@gmx.de>
To: ietf-http-wg@w3.org
On 27.02.2023 00:29, Mark Nottingham wrote:
> <https://github.com/httpwg/http-extensions/issues/2235>
> Editor hat on.
> In the retrofit draft, I listed a number of small fix-ups to improve parsing of existing compatible fields; see the issue for details.
> Discussion led us to believe that the best place to specify these fix-ups would be in sf-bis, since that's where the parsing algorithms are defined. However, changing the details of parsing -- even in small ways -- might lead to interoperability issues. That seems somewhat unlikely, but it's hard to rule out.
> One proposed solution would be to add a flag to parsing to indicate whether these fix-ups should be used. However, that introduces the possibility that the flag would be misused, and it makes parsing more complex.
> Stepping back, when I look at representative data (parsing fields sourced from the top ~100,000 sites' homepage loads), adding these fix-ups only improves success rates very marginally; if I remember correctly, we're talking about 0.1% difference at the very most, and often much less.
> So, that leaves us with three options:
> 1. Change the algorithms to always use the fix-ups (risking compatibility issues),
> 2. Add a flag to the algorithms to invoke the fix-ups (adding complexity and risk of misuse), or
> 3. Don't do the fix-ups at all (very slightly reducing the success rate of compatible header parsing in retrofit; note that it will never be 100%).
> Personally, my strong inclination is #3.
> Thoughts?

1 and 3 work for me. 2 IMHO creates unneeded complexity. All of these
options though are better than what the spec currently says (or used to
say) - suggesting some kind of preprocessing before passing things into
the SF parser.

Best regards, Julian
Received on Monday, 27 February 2023 13:20:20 UTC

This archive was generated by hypermail 2.4.0 : Monday, 27 February 2023 13:20:21 UTC