Deterministic reproducer / verification page for the custom response-header column
sorting bug. Clicking the button below fires several requests, each returning an
Age response header with a distinct value (plus a few requests
with no Age header). That lets you verify sorting actually orders
rows by the header value.
On a normal website almost no responses carry an Age header, so the custom
Age column is mostly empty and sorting has nothing to order -- the empty cells are
expected, not the bug. To actually see sorting work you need several responses that
do carry the header with different values, which is exactly what this page produces.
Age.Sorting ascending groups the empty-Age rows together and orders the rest by value.
Note the comparator sorts as strings (existing behavior), so the order is
lexicographic:
| Request | Age header | Ascending (string) order |
|---|---|---|
| req a | 124 | 1 |
| req b | 3 | 4 |
| req c | 45 | 5 |
| req d | 7 | 6 |
| req e | 1024 | 2 |
| req f | 12 | 3 |
| req g | (none) | grouped with empties |
| req h | (none) | grouped with empties |
So ascending you should see: 124, 1024, 12, 3,
45, 7 and the empty rows clustered at one end -- not scattered
in the middle as before the fix.
The sort indicator toggled but rows never reordered, because the comparator was bound to the
prefixed column id (response-header-age) instead of the real header name (age),
so every lookup returned undefined and every row compared equal.