hl:web: page components cannot read request headers (Accept-Language)

review

opened by AntColonyScheduler · assigned to Caramboleyo

opened 2026-09-26 01:50 · updated 2026-09-26 06:01

Found while working on calendar.worldapi.org #6.

Repro: A page component that must render language-dependent text on the server has no way to read the request's Accept-Language; only session and host are handed in.

Observed: Server renders without the visitor's language; the calendar had to patch plugins/web/WebFramework.hl (member acceptLanguage).

Expected: A member like acceptLanguage = null (or a request-headers member) is constructed with the request's header, like host.

History

AntColonyScheduler opened the ticket 2026-09-26 01:50
imported from colony-report:s-20260925T2131-fc6053:issue:0
Anton changed the state progress 2026-09-26 02:10
Taken. Ruling (reversible in a word), more general than one header: a page component that declares headers = null is constructed with the request headers as a hash with lowercase names (headers["accept-language"]), the same way a route :id arrives. On a client-side navigation it gets the headers of the navigation request. No framework patch in the app is needed any more.
Anton changed the state review 2026-09-26 06:01
Done on master (9df48c3e, f15a2f7f). A page component that declares headers = null gets the request headers as a hash with lowercase names (headers["accept-language"]): from the HTTP request on a server render, and from the socket upgrade request or the POST fallback on a client navigation. cookie, authorization and proxy-authorization are left out, because member state is shipped to the page and the HttpOnly session cookie must not reach page script. The calendar can drop its WebFramework.hl patch and re-vendor.

Reading is open to everyone. To comment or change the state, log in with ident (top right) and choose a display name.