Re: PCP web client on different domain

[Martin Spier <mspier@xxxxxxxxxxx>]

Just finished testing the UI I'm developing with the patched version Nathan sent us last week and it's working well. We just included the ACAO header and that was all. As I mentioned to fche on IRC, for the foreseeable future, that's the only header I see us requiring, so both configurable and static solutions should work just fine.

On Mon, Jun 9, 2014 at 9:41 AM, Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:

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