Accessor functions for response header

[kilianmh]

It might be convenient to have simple (syntactic-sugar) functions for accessing and setf'ing single response header.

A generic one would be:

(defun response-header (response header)
  (getf (response-headers response) header))

(defun (setf response-header) (value response header)
  (setf (getf (response-headers response) header)
    value))

Alternatively, or on top of that we could introduce access/setf functions for frequently used header (e.g. content-type, etc.):

(defun response-content-type (response)
  (getf (response-headers response) :content-type))

(defun (setf response-content-type) (value response)
  (setf (getf (response-headers response) :content-type)
    value))

Do you like the idea, or unnecessary code bloat @fukamachi ?

[fukamachi]

I used to be skeptical of the need for those functions because I didn't think end users would use Lack request objects directly; however, they do. It doesn't harm usability (people still can treat it as plist if needed), so it'd be great to have.

[kilianmh]

So then which Standard response fields should we include? All which are permanent and not obsolete? That would be a lot though. And which of the Common non-standard response fields?

[fukamachi]

Response headers that web applications would use are limited. I looked over applications I was involved in, but I found only content-type and access-control-* were set through request-headers. Not limited, but adding accessors for these is sufficient for me. Of course, it's fine to add more if you need any, though.

[kilianmh]

I looked over applications I was involved in, but I found only content-type and access-control-* were set through request-headers.

Yeah these are the basic ones that most use. However some people might want to use more exotic standard or Common non-standard fields.

Here are some candidates from HTTP Security Response Headers Cheat Sheet

• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options
• Referrer-Policy
• Strict-Transport-Security
• Content-Security-Policy
• Permissions-Policy
• Cross-Origin-Embedder-Policy
• Cross-Origin-Opener-Policy
• Cross-Origin-Resource-Policy
• Server

Is the prefix "response-" needed, or not?

(content-type response)

Should we also introduce set-* functions so one less parentheses is necessary:

(set-response-content-type response "application/json")
;; vs:
(setf (response-content-type response) "application/json")

Also a general-purpose functions to add/update multiple Headers in one go should be useful:

(set-headers response
             :content-type "application/json"
             :server "default")

[fukamachi]

Yeah these are the basic ones that most use. However some people might want to use more exotic standard or Common non-standard fields.

Here are some candidates from HTTP Security Response Headers Cheat Sheet

Yeah, I never used them, but it seems a good list to be added.

Is the prefix "response-" needed, or not?

Since other functions in Lack.Response, it's better to have a prefix of response-.

Should we also introduce set-* functions so one less parentheses is necessary:

I don't really like it, and maybe there's not much benefits.

Also a general-purpose functions to add/update multiple Headers in one go should be useful:

It looks neat. However, it's ambiguous how it works if it appends or replaces, and how it treats multiple HTTP headers with the same key, I think.