You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has been seen that when a UTF-8 encoded character is present in a label (specifically ★ - U+02605 - BLACK STAR), a Plack server handling serving the output from the ->format method directly (not using the internal ->psgi method) is truncated by a few bytes. This suggests something isn't coping with a mismatch in octet vs character lengths.
The problem was actually seen in something using Prometheus::Tiny::Shared, so the "problem" could exist anywhere in:
shared cached freeze/thaw
metric insertion
output formatting
the surrounding web server
If possible, we should ensure that P::T's internal PSGI handler does the right thing here. If it does turn out to be entirely an application-level concern, then we should perhaps document some guidance for users. At the very least, I'd like to understand the problem.
The text was updated successfully, but these errors were encountered:
It has been seen that when a UTF-8 encoded character is present in a label (specifically
★ - U+02605 - BLACK STAR
), a Plack server handling serving the output from the->format
method directly (not using the internal->psgi
method) is truncated by a few bytes. This suggests something isn't coping with a mismatch in octet vs character lengths.The problem was actually seen in something using
Prometheus::Tiny::Shared
, so the "problem" could exist anywhere in:If possible, we should ensure that P::T's internal PSGI handler does the right thing here. If it does turn out to be entirely an application-level concern, then we should perhaps document some guidance for users. At the very least, I'd like to understand the problem.
The text was updated successfully, but these errors were encountered: