> On Aug 11, 2016, at 9:59 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Aug 11, 2016 at 11:54 AM, Eric Covener <cove...@gmail.com > <mailto:cove...@gmail.com>> wrote: > On Thu, Aug 11, 2016 at 12:44 PM, William A Rowe Jr <wr...@rowe-clan.net > <mailto:wr...@rowe-clan.net>> wrote: > > Just to be clear, that is now 2 votes for eliminating the 'classic parser' > > from all > > of trunk, 2.4.x and 2.2.x branches, and using only the strict parser, > > unconditionally. > > > > That's actually 3 votes for removing it from trunk, which I planned to do > > already, > > after 2.4 and 2.2 backports are in-sync with trunk. > > Without yet reviewing the votes, I would (personally) think this kind > of split makes it your call as the one neck deep in the issue & doing > all the work. Thank you for your work on this. > > Maybe one last summary of your call, and a short window for strong > objection/veto? > > Certainly, that's what the backport proposal of everything from the initial > commit by sf all the way to the present state will accomplish in STATUS. > > With so many evolutions of various bits, a summary patch will be provided, > of course. But it's helpful to me to know the opinions of Jim and Roy and > everyone else in advance of proposing that backport.
I am having trouble keeping up while dealing with summer parenting issues. I have no doubt that a strict parser is necessary, for some definition of strict. I have no idea why there is any need to discuss EBCDIC here, since HTTP itself is never EBCDIC. We should not be transforming any input to EBCDIC until after the request has been parsed. I am not convinced that we need a wholesale rewrite of the parser code to accomplish anything. Since most of the changes to trunk were tossed and repeated multiple times due to unfamiliarity with the train parsing code or unawareness that the read is already handling obs-fold and spurious newlines, I still think we should just commit the simple fix (with your added logging statements) and remove the bits from trunk that we don't actually need. That doesn't mean we shouldn't attempt a better parser. However, I would like to review that as one clean diff with demonstrated performance tests. That means setting up a test harness and proving that it is actually better. For example, we might want to try using (or at least learning from) other parsers that can work on the entire received buffer in one pass, rather than limit ourselves to the existing line-at-a-time process, and simultaneously deprecate or remove handling of obs-fold and HTTP/0.9. In any case, if you have a working parser implementation, I will be happy to review it regardless of my preferences. If it is better than what we have, then it will still get my +1 for trunk regardless of longer term plans. ....Roy
