DateHeaderHandler: Unsupported Time‑Zone Offsets in HTTP Date Header

Vert.x Web’s DateHeaderHandler parses the HTTP Date header only when the value matches the RFC1123 format in GMT (e.g., Tue, 15 Nov 1994 08:12:31 GMT). A header with a non‑GMT offset, such as Tue, 15 Nov 1994 08:12:31 +0200, results in a parsing exception.

Developers must drop the header or implement a custom handler using java.time.DateTimeFormatter to apply zone conversion. An open GitHub issue requests optional support for arbitrary offsets, but no decision has been made.

Extending the handler would affect backward compatibility, request routing, caching, and performance. The trade‑offs of preserving the original offset versus normalizing to UTC are unclear.

• Should DateHeaderHandler be extended to accept arbitrary time‑zone offsets in the Date header?
• If extended, should the parsed value be converted to UTC or preserved with its original offset?
• What are the expected effects on caching semantics and request routing when non‑GMT dates are accepted?