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

On 16 January 2012 11:27, Dan Brickley <[email protected]> wrote:
>
>
>
>
> On 16 Jan 2012, at 11:23, Michael Hausenblas <[email protected]> wrote:
>
>>
>> Did you check http://enable-cors.org/#how-apache already?
>>
>
> Yup, and checked with the checktastic checker too. Those docs led me to use a virtualhost-wide 'set' header instruction instead of a per-directory .htaccess 'add'...

From Joe

Header always set Access-Control-Allow-Origin *
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) http://xmlns.com/foaf/0.1/$1 [R=303]

>
> Dan
>
>> Cheers,
>>    Michael
>> --
>> Dr. Michael Hausenblas, Research Fellow
>> LiDRC - Linked Data Research Centre
>> DERI - Digital Enterprise Research Institute
>> NUIG - National University of Ireland, Galway
>> Ireland, Europe
>> Tel. +353 91 495730
>> http://linkeddata.deri.ie/
>> http://sw-app.org/about.html
>>
>> On 16 Jan 2012, at 10:09, Dan Brickley wrote:
>>
>>> +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: ^
>>