Hi guys,
----- Original Message -----
> [...]
> git:// git.performancecopilot.org/nathans/pcp.git dev
>
> and test it. I will let Martin comment on whether such features should be
> configurable or hard coded. Do we know how other applications serving web
> clients are setting it? Any standard?
>From a bit of reading, it is a standard (optional) header. Other http
daemons will certainly allow its use to be configured. Client tools
usually allow for custom headers to be sent to servers (e.g. --header
options to curl(1), wget(1), and so on), and servers usually would have
similar configurability.
Franks point though is that pmwebd is not a general purpose web server,
so hard-coding any/all headers now-and-forever maybe OK. Or it may not;
its not a decision we have to enforce on users - making it customisable
is evidently trivial, coding-wise.
----- Original Message -----
> [...]
> Thanks Nathan for prototyping something far more flexible than called for
> this by request.
No problem at all, it's always good to think ahead.
> aather, mspier, et al., I'd like to hear your opinions
(yes, please do chime in guys - certainly I could be convinced hard-coding
is OK for pmwebd, I'm not tied to this approach if noone else wants it)
> about whether the extra configurability is needed or helpful, or whether
> simply hard-coding "A-C-A-O: *" is sufficient for forseeable purposes.
Other than dealing with the potential problems (like * not being the only
valid value for Access-Control-Allow-Origin, or people not wanting that
header at all, or the dazzling array of other standard http headers folks
might want to set), another potential situation where this flexibility
might help would be the use of custom headers for a custom webapp. Maybe
identifying something about the machine that isn't available as a metric,
perhaps helping locate it within a data centre - that kind of thing.
Given this lack of flexibility has caused a problem once, it'll probably
come up again.
cheers.
--
Nathan
|