On Sep 17, 2009, at 12:39 AM, Paul Davis wrote:
I'm not sure how to interpret that statement. I'd like to
interpret as an
willingness to consider for configurable headers.
Absolutely! Its on my whiteboard. Configurable headers are an
excellent solution here because they're a generic feature that can be
used to solve the issue at hand. As much as I dislike adding hacks for
specific user agents, I do like adding generic capabilities to allow
flexibility.
HTH,
Paul Davis
One issue to be noted is that if multiple values for the same header
appear in the call to mochiweb, they will be merged into a comma
separated list. It is a good feature, except when you have header
attributes that are mutually exclusive or inconsistent. In my Expires
patch, I had to remove the Expires header from the uuid code in order
not to have comma separated list of dates.
What I think that would mean is you might do the equivalent of changing:
send_json(Req, Code, Value) ->
send_json(Req, Code, [], Value).
send_json(Req, Code, Headers, Value) ->
DefaultHeaders = [
{"Content-Type", negotiate_content_type(Req)},
{"Cache-Control", "must-revalidate"},
{"Expires", "Fri, 01 Jan 1990 00:00:00 GMT"}
],
Body = list_to_binary(
[start_jsonp(Req), ?JSON_ENCODE(Value), end_jsonp(), $\n]
),
send_response(Req, Code, DefaultHeaders ++ Headers, Body).
to:
send_json(Req, Code, Value) ->
DefaultHeaders = [
{"Content-Type", negotiate_content_type(Req)},
{"Cache-Control", "must-revalidate"},
{"Expires", "Fri, 01 Jan 1990 00:00:00 GMT"}
],
send_json(Req, Code, DefaultHeaders, Value).
send_json(Req, Code, Headers, Value) ->
Body = list_to_binary(
[start_jsonp(Req), ?JSON_ENCODE(Value), end_jsonp(), $\n]
),
send_response(Req, Code, Headers, Body).
Which would mean that any code that wants to provide non-default
headers (other than the calculated Date, etc) is responsible for
assembling the full list of headers. Last I checked, only the uuid
code called the 4 parameter send_json, but that might have changed.