- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 3 Mar 2023 11:15:42 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
Thanks everyone for the input. It sounds like #3 is the way to go, so I'm going to close the issue. See also: https://github.com/httpwg/http-extensions/commit/82e83b5a44db Cheers, > On 27 Feb 2023, at 10:29 am, Mark Nottingham <mnot@mnot.net> 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? > > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 3 March 2023 00:16:17 UTC