Hi Amer,
----- Original Message -----
> Our client application is running on a different instance than the one
> serving PCP. That means for all JavaScript API requests to PCP server we
> need to include an extra header in order for our browser client to accept
> the response:
>
> Access-Control-Allow-Origin: *
>
> This is fairly standard on any API that is meant to be used by external
> clients.
>
> Do we need to enable some configure option in PCP in order to make it work?
Following up on some IRC chat today ... there's no way to set specific
headers currently with pmwebd. I've made a modified version of pmwebd
which adds in a -r option for the daemon, allowing additional headers
to be set via a config file. You can find it in my development branch:
git://git.performancecopilot.org/nathans/pcp.git dev
commit 84fab331bce01d737a95dfe245cfbbc082bdcdfa
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu Jun 5 19:10:59 2014 +1000
Provide a pmwebd mechanism for user-specified response headers
The Netflix folks have come across a case where they need to be
able to set a specific HTTP header in the pmwebd JSON response;
in particular, the "Access-Control-Allow-Origin" header.
Add in a -r/--headers option to pmwebd, which provides a config
file containing user-specified headers that should be set in the
responses. This simply sits in front of the libmicrohttpd API
for adding response headers, and should be future-proof.
$ grep headers /etc/pcp/pmwebd/pmwebd.options
# allow additional response headers to be set, e.g.
-r /etc/pcp/pmwebd/pmwebd.headers
$ ps -ef | grep pmwebd
pcp 1129 1 0 18:52 ? 00:00:00 /usr/libexec/pcp/bin/pmwebd -r
/etc/pcp/pmwebd/pmwebd.headers
$ cat /etc/pcp/pmwebd/pmwebd.headers
Access-Control-Allow-Origin: *
# Cache-Control: no-cache
Cache-Control: private
Connection: keep-alive
Pragma: no-cache
$ curl -s -S "http://localhost:44323/pmapi/context?local=anything";
--dump-header -
HTTP/1.1 200 OK
Content-Length: 23
Pragma: no-cache
Connection: keep-alive
Cache-Control: private
Access-Control-Allow-Origin: *
Content-Type: application/json
Date: Thu, 05 Jun 2014 08:52:47 GMT
{ "context": 16726391 }
There's still some discussion about whether we should hard-code all headers,
or whether the headers should be configurable (clearly, I favour the later!)
... but, one way or the other, this will be resolved in pcp-3.9.5 which is
scheduled to release in just under two weeks.
Amer/Martin, if you guys could try the above code out & verify it meets your
needs, that would be great (please let me know).
Frank, could you review the above please and see if the generalised header
specification mechanism is sufficiently light-weight? Thanks! I imagine
some possible future header values might need more state than a static file
can give; those we'd have to tackle on an as-needed basis, I guess, using
wildcards or something else that expands at runtime? Either way, hardcoding
all of this stuff certainly makes no sense to me (some people may not want/
need this or other headers at all of course ... so configure 'em I say!).
If the above commit looks OK, I'll go ahead and automate the above test and
add in more error-handling tests. And possibly add a pwmebd valgrind test,
since that appears to be missing, if time permits before the weekend.
cheers.
--
Nathan
|