[foaf-dev] Enabling CORS on xmlns.com for browser .js access to FOAF and WOT vocab documentation

+Cc: Michael, FOAF list

On 15 January 2012 16:35, Melvin Carvalho <[email protected]> wrote:
> Hi Dan
>
> I was wondering if you are the maintainer of xmlns?
>
> If so, would it be possible to turn on CORS?

(ie. http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing for
those on the list not familiar; it's a header allowing cross-domain
access from browser .js)

> Access-Control-Allow-Origin: *

Here's the log from #dig, not sure if you caught it all. Conclusion so
far: we have it enabled now for all of xmlns.com except for those URLs
that respond with a 303.

The server is Apache 2, and the 'set header' line is right there at
the top of my virtualhosts directive in the main config. Details
linked below.

We're stuck now, in figuring out how to get the CORS header included
in 303, ... but with some suspicion that browser behaviour might allow
the seeAlso 303 refs to be traversed from .js without them. That said,
the checked on enable-cors.org asserts that
<http://xmlns.com/foaf/0.1/Person> is not CORS-ified...

Suggestions? Anyone here have time to check out the relevant specs,
browser behaviour, and/or Apache 2 config intricacies? What are other
303-redirecting, Apache-hosted RDF vocabularies doing?

Dan

21:43 melvster: im not 100% sure how is the 303 generated?
21:43 danbri: see url above for the .htaccess; it's all public
21:44 danbri: and the site config is roughly this:
21:44 danbri: https://gist.github.com/1617141
21:44 danbri stripped some details
21:46 danbri: hmm
http://stackoverflow.com/questions/6491419/apache-ignoring-php-headers-when-sending-a-304
21:48 danbri: ok, it seems to be an http/apache/complications issue!
21:48 danbri: 'unrecognised headers are treated as entity-headers.
w3.org/Protocols/rfc2616/rfc2616-sec6.html '
21:48 danbri: ' the response MUST NOT include other entity-headers;
this prevents inconsistencies between cached entity-bodies and updated
headers.'
21:48 danbri: PURL presumably will suffer this issue :/
21:48 presbrey: I think on
http://svn.foaf-project.org/foaf/trunk/xmlns.com/htdocs/foaf/0.1/.htaccess
21:49 presbrey: Header add Access-Control-Allow-Origin "*" early
21:49 presbrey: * try adding early
21:49 danbri will comment out 'Header add Access-Control-Allow-Origin
"*" ' as the server sets it now, and we'll get two headers
21:49 danbri: though in fact it's confusing re foaf/spec/ and foaf/0.1/ ...
21:49 presbrey: another option, on the 303 below, try adding [H=] to Redirect
21:50 presbrey: yes I chdir'd, a few .htaccess under foaf
21:50 danbri: so
21:51 danbri: Redirect 303 /foaf/0.1/dnaChecksum http://xmlns.com/foaf/spec/
21:51 danbri: becomes
21:51 presbrey: I meant adding [H=] to RewriteRule
21:51 danbri: ah
21:51 presbrey: no I see those are not RewriteRules now
21:51 presbrey: but if they were...?
21:51 danbri: we had trouble with previous use of rewriterules
21:51 presbrey: I think adding *early* to Header add/set might be enough
21:51 danbri: i forget what now
21:51 danbri: have a look at that stackoverflow link
21:51 danbri: someone there complaining their cors headers aren't
passed on, and the explanations are all at the HTTP/Apache level
21:52 presbrey: but we already know CORS headers work with apache
21:52 danbri: and with 303?
21:53 presbrey: the article you pasted is about 304 right?
21:55 danbri: ah I misread this: 'I re-run few tests (after my initial
comment) and yes -- custom header got removed for 304, but is present
for 404 and other non 3xx codes (checked with 302, 303, 305, 306). '
21:55 danbri: I thought they said it was missing for those too
21:58 danbri: ah, i have a theory
22:00 danbri: nope
22:00 danbri: i thought the site-wide cfg was setting the header, and
the surviving 0.1/.htaccess was ADDing another, screwing things up
22:00 danbri: but seems not; here is before-and-after that fix. identical.
22:00 danbri: https://gist.github.com/1617311
22:02 danbri: presbrey, if you care to suggest a complete htaccess (or
site config) i'm up for trying it
22:02 danbri: trouble with apache for me is I only RTFM annually :/
22:07 danbri: 21:51 presbrey: I think adding *early* to Header add/set
might be enough
22:07 danbri: doesn't putting it in VirtualHosts for whole site add it
maximally early?
22:11 oshani has left IRC (Quit: Mama nidi!)
22:28 melvster: lol i found this
http://nevali.net/post/1620606776/demystifying-rdf-part-ii
22:29 melvster: curl -L -i -H 'Accept: application/rdf+xml'
http://xmlns.com/foaf/0.1/Person
22:29 melvster: Access-Control-Allow-Origin: *
22:30 melvster: so that comes with the 200 but not with the 303 .... is that ok?
22:44 oshani has joined (~oshani-8hW6YF7EBfJ8Xzg2HSNGgX/[email protected])
23:05 melvster has left IRC (Ping timeout: 260 seconds)
23:15 danbri: if .js tries to deref the /Person version, presumably it'll fail?
23:15 danbri: or maybe browser allows access to the redirects even if
not the content?
23:42 rszeno has left IRC (Quit: Leaving.)
23:47 timbl: you mean with XMLHTTPRequest?
23:49 rszeno has joined (~rszeno-SiX8IHd2dXbB/jF5/[email protected])
23:56 manu1 has left IRC (Ping timeout: 240 seconds)
23:56 timbl: sorry i didn't see the context.
23:57 cheater: danbri: http requests done by javascript are like any
other http requests and obey any headers you send out, including
redirections.
23:58 danbri: assuming they get past the browser sandbox in the first place...?
00:00 cheater: cross domain policy applies.
00:00 cheater: try asking in #web, they know a lot about this stuff.
00:00 danbri: I think we're talking past each other
00:00 cheater: explain
00:01 danbri: the problem here is that doing the obvious/recommended
thing to add CORS headers to xmlns.com, ... got the headers added for
normal doc access
00:01 danbri: but when accessing URLs that are 303 redirected, we
don't see the headers
00:02 danbri: hence the concern that e.g. if .js tries to fetch
<http://xmlns.com/foaf/0.1/Person> (which 303 redirects to
<http://xmlns.com/foaf/0.1/>) ... the fact that we've got CORS headers
on the latter URL is useless, since .js might not be able to get that
far
00:03 danbri: does that make sense to you?
00:04 danbri: apache cfg is roughly https://gist.github.com/1617141
which was based on http://enable-cors.org/
00:04 cheater: why do you not see the headers?
00:04 danbri: because they are not there
00:04 cheater: are you fetching the headers from the first http
connection that you make *only*?
00:05 danbri prepares a transcript
00:05 cheater: that would be incorrect, you should be fetching headers
from the final url, after all redirects
00:05 cheater: (if there are too many redirects, throw an error)
00:06 danbri: well that was the question above, whether the browser
would allow knowledge of the redirect to propagate to .js, since the
first url wasn't CORS-ified
00:07 danbri: try this url, http://xmlns.com/foaf/0.1/ ...in the form
at http://enable-cors.org/ ... then try
http://xmlns.com/foaf/0.1/Person
00:08 danbri: it might be a bug in the form, probably worth trying directly
00:08 danbri: anyway, it's midnight!
00:08 danbri turns into a pumpkin
00:08 cheater: ok, i see what you mean
00:09 cheater: in this case the browser should not allow access
00:09 cheater: danbri: ^