Clojurians Log v2
ring
is there any interest in supporting storing information relating to the order of headers in Ring? For the context of how I got to thinking about this, see the discussion over at https://github.com/pedestal/pedestal/issues/930. Specifically, this is why storing this info might be helpful:
• to determine which header is the last for the purposes of dealing with multiple singleton fields (`Content-Type` https://www.rfc-editor.org/rfc/rfc9110.html#section-8.3-7 in RFC9110)
• for cases where duplicate headers are sent and it matters what order they are sent in (e.g. X-Forwarded-For)
is there a reason why request header names are https://github.com/ring-clojure/ring/blob/master/SPEC.md#headers in the spec; but nothing is said of response header names?
HTTP headers are case insensitive, so in order to get a predictable key, they are lowercased in the request map. However, the headers in the response are placed there by the developer, and they may have reasons for choosing a particular case. For example, perhaps they're working with a faulty client that expects an exact header string, matched case-sensitively. It's also more common for middleware to need to read headers in the request than the response.
sure. Here's one question to help clarify things: does all middleware theoretically need to conform to the spec? or does "request" and "response" only refer to the actual beginning and end of the entire "pipe"?
Ring middleware is specifically defined as a function that transforms a Ring handler into another Ring handler. However, there's nothing stopping you inserting a function into the chain that doesn't do this; it just wouldn't be Ring middleware.
right! sorry about that. Yes you're right...
Probably to make it predictable when reading them across middlewares
thanks. I think i get it now; there is no specific requirement per se for response maps (after all, header names are case-insensitive for HTTP), but practically, because of the requirement for lowercase for request maps, effectively then response maps are the same because of the architecture of how things are: middleware, etc. One component’s response map tends to be the request map for the next!