-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop using decodeUtf8 #53
Comments
Nah, if the invalid data is due to the data being latin1, why not falling back to it?
|
Can you elaborate on why we should assume (or optimize for) that? |
My assumption might be wrong here (wrongly assuming it’s HTML, where it mostly is latin1 or utf8). Coming only from my recent experience with it with HTML. What’s the cause of the invalid data in your case? Is it something different than utf8 or latin1? |
I haven't encountered a known case, this was more of a hypothetical that the content "could be anything" since we don't control it as the 3rd-party library. At least, that's how I interpreted it. It was raised here by @chris-martin. So, if the nature of this issue was "this can be anything", then a fix that assumed (or favored) latin1 felt like it was kind of missing the point. But I thank you for your comment because it did get me to take a second look here. And this whole Issue is kind of silly. This function is currently used on:
I think it's safe to say our current uses of Given that, I'd be OK with using the throwing-version of blammo/Blammo-wai/src/Network/Wai/Middleware/Logging.hs Lines 227 to 228 in ca12432
|
We use
decodeUtf8
in a few places, which will throw on invalid data. Since we don't know what we're logging, and us throwing would be pretty disruptive, let's not do that.decodeUtf8With lenientDecode
should be better, as that'll insert replacement characters instead.The text was updated successfully, but these errors were encountered: