[Mulgara-general] firefox bug and server config

[Gregg Reynolds]

On Sat, Sep 5, 2009 at 1:13 PM, Paul Gearon <gearon at ieee.org> wrote:

>
> Ouch. I'm trying to catch up on my time away (while I moved) so I
> really don't see that I'll have much opportunity to get to something
> so involved right now.


If you can tell me how to make Jetty return the proper
Access-Control-Allow-Origin<http://www.w3.org/TR/access-control/#access-control-allow-origin-response-hea>
header
I'll make lots of test cases.  Actually it would suffice for my purposes at
the moment if I could hardcode the header to "http://localhost". But the
default server config should probably have a rule that says "if the Request
has an Origin: http://localhost header, then the Response should set a
Access-Control-Allow-Origin: http://localhost header."  The relevant
passages <http://www.w3.org/TR/access-control/#introduction> from the CORS
spec are:

"A resource can include an
Access-Control-Allow-Origin<http://www.w3.org/TR/access-control/#access-control-allow-origin-header>
header,
with the origin of where the request originated from as the value, to allow
access to the resource's contents.

"The user agent validates that the value and origin of where the request
originated match.  [NB: this is why ajax requests to localhost:8080
currently fail on FF 3.5 - it apparently checks the reponse headers against
the Origin header of the request.]

"Server-side applications are enabled to discover that an HTTP request was
deemed a cross-origin request by the user agent, through the
Origin<http://www.w3.org/TR/access-control/#origin-header>
 header.

"This extension enables server-side applications to enforce limitations on
the cross-origin requests that they are willing to service.  [NB: So it
should be easy for the admin to list the domains to be serviced, but for the
moment I don't need that.]"

> But facilitating AJAX would certainly be a Good Thing (TM).


Think tutorial.  A simple web page that throws ajax queries at Mulgara.  The
user can then use FF dev tools to inspect the details.   You could do the
same with curl (I'm putting one together now), but a little ajax never
hurts.


> >
> > That's a Good Thing.  There's something terribly, cosmically wrong about
> a
> > configuration language that uses XML to encode a programming language,
> > especially if said language is as supernaturally ugly as Java.  But I
> > digress.
>
> I'm not sure I follow your complaint here. You may be talking about
> something I haven't had to configure before (encoding a programming
> language? You mean, something like an AST of Java in XML?). On the
> other hand, I've definitely decided that I don't like Java either.
> :-)


Sorry, looking at Jetty's configuration language made me grumpy.  Unless
I've misunderstood something, it basically asks the user/admin to learn the
Jetty Java API in order to code a configuration, by writing Java in XML.
 It's unbelievable.  Any configuration language that requires me to read
Java API documentation in order to accomplish a simple task like setting a
header is not my friend.  (Compare the HTTP Header module of nginx).  I'm
sure I could figure out how to set the proper Access-Control-Allow-Origin
header, but it would probably take me a week and it would put me in a really
bad mood. ;)

(I suspect this ghastly design is left over from the (thankfully brief)
period when absolutely everything, everywhere, just had to be XML.   But
config language is one area where a Domain-Specific Language is clearly the
way to go.)


> That said, it can be hard to find things in documentation at the best
> of times. I'd love to set it up to make it easy for people to find
> what they need, but I really don't know how. It's not feasible to just
> tell people that something is "in the wiki" if they have to read the
> whole thing before they find what they need.


I've been thinking about that.  Once a sufficient amount of detail is
accumulated on the wiki it will be time to write some kind of "Definitive
Guide", organizing it all according to some kind of plan.  The stuff under
"Draft Documentation" is an admittedly feeble attempt to begin by trying
various categorizations of stuff.  My instinct is to start by architectural
"service categories", which is why I was asking about e.g. the details of
resolvers - wasn't sure how to classify them in terms of service category.


> >> > http://bitbucket.org/gar/mulligan/overview/ in case anybody's
> >> > interested.
> >>
>
> OK. It's just that describing it as competing with the CLI made it
>

My bad; "it complements the CLI" was how I should have put it.

>
> It might be worth making this work with SPARQL2, since almost
> everything in TQL will be present there, and it will be more portable.
> SPARQL2 is a long way from completion, but a lot of it is pretty much
> worked out already (eg. Look at SPARQL/Update from Jena).


Thanks, I'll take a look.

-gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20090906/d317320b/attachment.htm>