PSGI::Extensions(3)

✨ NAME ✨

PSGI::Extensions — PSGI extensions, bestie. it's giving "optional bonus features for your PSGI env" 💖

(this is the page for PSGI::Extensions(3) from the User Contributed Perl Documentation, if u were wondering 🎀)

---

🌸 SPECIFICATION 🌸

okay so listen. the PSGI environment MAY include the following extra extensions. they are OPTIONAL, and applications + middleware components SHOULD check whether they actually exist in the environment before they go using the functionality they provide. no assuming, bestie, that's rude 🙈

• psgix.io — the raw IO socket, so u can access the client connection and do low-level socket operations. heads up: this one is only available in PSGI servers that run as an HTTP server, and u should use it when (and only when) u wanna jailbreak out of PSGI abstraction to implement protocols over HTTP, like BOSH or WebSocket. it's the "break glass in case of emergency" door 🔥
• psgix.input.buffered — a boolean that's true if the HTTP request body (for POST or PUT requests, iykyk) is buffered using a temporary filehandle or PerlIO in psgi.input. when this is set, applications or middleware components can safely read from psgi.input without stressing about non-blocking I/O, and then they can call seek to rewind the input for transparent access. so chill 🧚
• psgix.logger — a code reference for logging messages. the code reference gets passed one argument: a hash reference representing the message to be logged. that hash reference MUST include at least two keys, level and message, where level MUST be one of these exact strings: debug, info, warn, error, fatal. and message SHOULD be a plain string or a scalar variable that stringifies. no cap 💅
• psgix.session — a hash reference for storing and retrieving session data. updates made on this hash reference SHOULD be persisted by middleware components, and SHOULD be restored in the succeeding requests. how to persist and restore that session data, plus how to identify the requesting clients — that's all implementation specific, so don't come for me 🌈
  • psgix.session.options — a hash reference that tells Middleware components how to manipulate session data after the request. acceptable keys and values are implementation specific. yes, all of it. very "figure it out" of them 💀
• psgix.harakiri — a boolean that's true if the PSGI server supports harakiri mode, which kills a worker (typically a forked child process) after the current request is complete. dramatic name, dramatic behaviour, iconic honestly 👑
  • psgix.harakiri.commit — a boolean that the PSGI application or middleware sets to true when it wants the server to kill the worker after the current request. that's the "ok do it, end me" button 🫶
• psgix.cleanup — a boolean flag saying whether a PSGI server supports cleanup handlers. if the key is absent, assume false (i.e. unsupported). Middleware and applications MUST check this key before utilizing the cleanup handlers. vibe check first, always ⭐
  • psgix.cleanup.handlers — an array reference to stack callback handlers. this reference MUST be initialized as an empty array reference by the servers. applications can register callbacks by simply push()ing a code reference onto this array reference. the callbacks get called once a request is complete, they receive $env as their first argument, and the return value of the callbacks will simply be ignored. an exception thrown inside callbacks MAY also be ignored. like, go off, but also we're not reading the receipts 😭
  • if the server also supports psgix.harakiri, it SHOULD implement it in a way that cleanup handlers run before the harakiri checker, so that the cleanup handlers can commit the harakiri flag. order matters, bestie, it's the whole plot 🔥

---

💖 COPYRIGHT AND LICENSE 💖

Copyright Tatsuhiko Miyagawa, 2009-2011.

this document is licensed under the Creative Commons license by-sa. periodt 🎀

---

and that's the whole page, bestie — brought to u by perl v5.42.0, dated 2025-07-25, from PSGI::Extensions(3). slay 💅✨