Parse the HTTP Last-Modified zone as the literal GMT, not %Z#111619
Parse the HTTP Last-Modified zone as the literal GMT, not %Z#111619thevar1able wants to merge 3 commits into
Conversation
RFC 7231 IMF-fixdate always ends in the literal "GMT", but the parser matched it with strptime's %Z. That is not portable: musl's %Z only knows the names of the currently configured local time zone, so a zero-length tzname match consumes nothing, "GMT" is left unparsed, the full-consumption check fails, and the _time virtual column of the url table function is always NULL (04104_url_time_virtual_column failed on every musl configuration). If the time zone database has not been initialized yet, musl's %Z even dereferences a NULL tzname[0]. Match the literal instead; verified to parse identically on musl (with and without tzset) and glibc.
|
Workflow [PR], commit [68ff5ad] AI ReviewSummaryThis PR fixes the musl-specific Findings
Tests
Final Verdict
|
| String date_str = response.get("Last-Modified"); | ||
| struct tm info{}; | ||
| char * end = strptime(date_str.data(), "%a, %d %b %Y %H:%M:%S %Z", &info); | ||
| char * end = strptime(date_str.data(), "%a, %d %b %Y %H:%M:%S GMT", &info); |
There was a problem hiding this comment.
Last-Modified is an HTTP-date, and recipients are supposed to accept the two obs-date layouts in addition to IMF-fixdate. Hard-coding a single "%a, %d %b %Y %H:%M:%S GMT" parse still leaves headers like Friday, 13-Mar-26 10:54:50 GMT and Fri Mar 13 10:54:50 2026 unparsed, so _time stays NULL and the Last-Modified-based cache validation paths remain disabled for servers that emit those legal spellings.
Can we fall back to the rfc850-date and asctime-date layouts here, or switch this to a dedicated HTTP-date parser, instead of supporting only IMF-fixdate?
Parse the HTTP
Last-Modifiedheader's time zone as the literalGMTinstead ofstrptime's%Z.RFC 7231 IMF-fixdate always ends in the literal
GMT, butparseFileInfoinReadWriteBufferFromHTTPmatched it with%Z, which is not portable. musl's%Zonly knows the names of the currently configured local time zone, so a zero-length match consumes nothing,GMTis left unparsed, the full-consumption check fails, and the_timevirtual column of theurl/urlClustertable functions is alwaysNULL. If the time zone database has not been initialized yet, musl's%Zcan even dereference a NULLtzname[0]. Matching the literal parses identically on musl (with and withouttzset) and glibc.This is why
04104_url_time_virtual_columnfailed on every musl configuration; that existing test guards the fix.Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Fixed the
_timevirtual column of theurl/urlClustertable functions always beingNULLon musl-based builds, caused by non-portable parsing of the HTTPLast-Modifiedheader's time zone.