nathans wrote:
> [...]
>> 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.
mspier advised on IRC that in his opinion, it was sufficient.
> 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)
That's what the forseeability question is about. So far, the
configurability seems unnecessary.
> 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.
I haven't ever heard of such site data being provided as webapp ajax
response headers, or indeed webapps pulling in response headers for
such metadata. pmwebd already has a basic file server, where fixed
information can be easily provided, with more structure and
capability.
- FChE
|