On Wed, Jul 17, 2019 at 12:38 AM Barry Scott email@example.com wrote:
But if your use cases call for performance, it is perfectly fine to understand the tradeoffs, and opt in to the more appropriate solutions. And, of course, maybe there is a solution that could satisfy *both*.
Generally speaking, though, do you see 1 millisecond spent on parsing a URL deal breaker? I sense that some web frameworks might not like that very much, but I don't have any concrete use case to quote.
Yes 1ms would be a serious issue.
I guess what I'm concerned about is the use of a universal parser for a benefit I'm not clear exists having a terrible affect of the speed of code that is secure and correct.
I hope you are doubting that *my* library has not proven itself yet, rather than the benefit if a proper parsing package. If it was about the second, perhaps these links could convince you that URL parsing was simply not "secure and correct":
https://www.cvedetails.com/cve/CVE-2019-10160/ urlsplit and urlparse regress from the fix below. https://www.cvedetails.com/cve/CVE-2019-9636/ urlsplit and urlparse vs unicode normalization. https://bugs.python.org/issue30500 urlparse's handling of # in password
And many more related to HTTP header, cookie, email... These things are tricky.
It is fair to use the numbers I currently have (~900 usec vs 13 usec per parse) to ballpark the impact but I'm pretty confident that performance will sort itself out acceptably, eventually (and even with an entirely different library).
If 1ms is a deal breaker, what is a more palatable latency? How much latency would you trade for security?