Hi again,
> I
> _thought_ it was as easy (in this case) as setting the Access-Control-
> Allow-Origin header to * in response to the OPTIONS request, but
> apparently there's more to it as that didn't work in my five-minute
> test, which is all I have time for this morning.
Well, I got to thinking that I really needed to know more about CORS,
so I read key parts of the spec and realized I was being a *bit* too
simplistic, but wasn't a million miles off.
Adding the following to both the OPTIONS response and to the actual
request response (the GET or POST) allows any origin to query my JSP
with a CORS-enabled browser and so makes things work for me in Firefox
and Chrome in your local-file-requesting-web-resource scenario (as
well as my port 8080 => port 8701 scenario):
response.addHeader("Access-Control-Allow-Origin", "*");
response.addHeader("Access-Control-Allow-Methods",
request.getHeader("Access-Control-Request-Methods"));
response.addHeader("Access-Control-Allow-Headers",
request.getHeader("Access-Control-Request-Headers"));
What that's doing (line by line) is:
1. Allowing *any* origin to do the request (Access-Control-Allow-
Origin: *). This is probably a bad idea unless you really do want to
make the resource globally accessible (but then, there are lots of
valid use cases for that). To lock it down a bit more, your best bet
is to examine the "Origin" request header
(request.getHeader("Origin")) and determine whether you want to allow
access from that origin and if so echo that value back for your Access-
Control-Allow-Origin response header. The Origin I get when requesting
from a file:// resource is null, which is intresting, so in your
scenario you'd probably have to use "*".
2. Allowing the request to use the methods (and only the methods) it's
asked to use. Alternately you could just say "GET, POST" if you wanted
to allow GET and POST, but it seems a bit silly to allow more than
they've asked for. You might, of course, allow *less* than they've
asked for, in which case (in theory) they might adjust what they're
doing.
3. Allow the request to use the headers it's asked to use. Once again,
you may wish to limit what headers they can use, but this was the key
bit I was missing previously.
Caveat user: I'm learning this stuff, I can't say that the discussion
above is thorough (read the W3 doc) or informed (it isn't). But it's
plenty to allow you to do something internal like your example. I
would just read up a lot more before doing anything publicly-
accessible.
Happy coding,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Mar 16, 8:49 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi,
>
> > T.J, thanks for your reply as well. The answer to your first question
> > (the URL of the page that this is part of) is that I'm just having an
> > HTML file sitting on my desktop.
>
> AH. That's a very significant piece of information there. :-) Without
> it, we're all assuming you're serving the original page from a web
> server.
>
> I've replicated the results you're getting. My suspicion is that if
> you modify your servlet to handle the OPTIONS method (doOptions[1]),
> you'll find that both Firefox and Chrome are sending an OPTIONS
> command to the servlet asking it whether it's accessible to the file://
> origin you're requesting from. This is part of CORS[2][3], the new
> cross-origin resource sharing stuff. IE apparently doesn't think that
> it's a cross-origin request and so it's simply doing the request, not
> applying the SOP[4].
>
> I haven't gotten into CORS much yet. The basic thing is that the
> browser asks the target resource (via the OPTIONS method) whether it's
> okay for the origin to access that resource. If the origin replies
> with response headers allowing the original request, the browser
> performs the original request (GET, POST, whatever). If not, it
> disallows the request, which is what you're seeing. If you search for
> CORS examples on the web, I expect you'll find at least one in Java. I
> _thought_ it was as easy (in this case) as setting the Access-Control-
> Allow-Origin header to * in response to the OPTIONS request, but
> apparently there's more to it as that didn't work in my five-minute
> test, which is all I have time for this morning.
>
> Good luck with it!
>
> [1]http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServlet....)
> [2]http://www.w3.org/TR/cors/
> [3]https://developer.mozilla.org/En/HTTP_access_control
> [4]http://en.wikipedia.org/wiki/Same_origin_policy
>
> --
> T.J. Crowder
> Independent Software Consultant
> tj / crowder software / comwww.crowdersoftware.com
>
> On Mar 15, 2:10 pm, Ronen <rrotst...@gmail.com> wrote:
>
>
>
> > Thanks for correcting me on ActiveX... I didn't know that internally,
> > an XMLHttpRequest object gets used in the end.
>
> > In response to disccomp, I'm not sure how I would use a relative URL.
> > Could you give an example? I've tried using a value such as /MyApp/
> > MyServlet, but this doens't work at all (even in IE), which I can
> > understand since this is not specifying exactly how to reach the
> > servlet.
>
> > T.J, thanks for your reply as well. The answer to your first question
> > (the URL of the page that this is part of) is that I'm just having an
> > HTML file sitting on my desktop. This is the HTML file that I'm
> > loading up in IE, Firefox, and Chrome. So it's not part of any web
> > app, but rather just tries to invoke a servlet on a web app that is
> > currently deployed. Would this make a difference? (If so, how can we
> > explain why it works on IE?) In any case, I can and will try to load
> > an HTML file that is part of the same web app (since that's the
> > overall intent anyways), but I guess I'm not very confident in this
> > fixing the issue.
>
> > Also, the reason I use 8701 is because I'm trying this at work where
> > I'm using WebLogic (and the port is set up as 8701), but on my home
> > machine, I am using tomcat so I use 8080 like you did.
>
> > On Mar 15, 4:25 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > > Hi,
>
> > > > From IE, it works just fine
> > > > (probably because it's using ActiveX rather than XMLHttpRequest)
>
> > > Not *rather than* -- it's using XMLHttpRequest regardless. On older
> > > versions of IE, the way you get one is via ActiveX, but that's
> > > irrelevant (and only older versions); it's an XMLHttpRequest
> > > regardless.
>
> > > > var asyncReq = new Ajax.Request("http://localhost:8701/MyApp/
> > > > MyServlet", opts);
>
> > > What's the URL of the page this is a part of? Because the fact you've
> > > given a full URL there makes me think this is not relative to the
> > > page, which makes me wonder if you're running afoul of the Same Origin
> > > Policy[1] (because remember, different ports are different origins).
> > > But in that case, I wouldn't expect IE to work, either, not even IE6.
>
> > > When I try this in my setup, requesting from localhost:8080 to
> > > localhost:8701, using IE7 I simply get an access denied error and my
> > > servlet (okay, it's a JSP for test purposes) is never triggered at
> > > all. When I try this from Firefox or Chrome, because they support
> > > CORS[2][3], I see the OPTIONS request to my JSP seeking permission for
> > > cross-origin requests.
>
> > > [1]http://en.wikipedia.org/wiki/Same_origin_policy
> > > [2]http://www.w3.org/TR/cors/
> > > [3]https://developer.mozilla.org/En/HTTP_access_control
>
> > > FWIW,
> > > --
> > > T.J. Crowder
> > > Independent Software Consultant
> > > tj / crowder software / comwww.crowdersoftware.com
>
> > > On Mar 12, 2:53 pm, Ronen <rrotst...@gmail.com> wrote:
>
> > > > I've downloaded the latest prototype (version 1.6.1) and tried to call
> > > > a java servlet using Ajax.Request. From IE, it works just fine
> > > > (probably because it's using ActiveX rather than XMLHttpRequest), but
> > > > I'm having no luck with Firefox (v3.6) and Chrome (4.0).
>
> > > > The servlet that I'm calling performs a log operation right away so I
> > > > can see whether it was called or not. That's how I know that IE is
> > > > successful but firefox and chrome aren't.
>
> > > > I've used Firebug to try to debug firefox and I see that the line
> > > > this.transport.send(this.body);
> > > > is, in fact, being called by firefox. But still, my servlet shows no
> > > > log of being called.
>
> > > > The exact javascript I'm using is below:
> > > > var opts = {
> > > > method: 'post',
> > > > parameters : { key:"value" },
> > > > onSuccess: function(transport)
> > > > {
> > > > var d = new Date();
> > > > document.getElementById("location").value =
> > > > d.getTime();
> > > > }
> > > > }
> > > > var asyncReq = new Ajax.Request("http://localhost:8701/MyApp/
> > > > MyServlet", opts);
>
> > > > As you can see, in the success method, I just populate a textbox to
> > > > have the current date/time, and this actually works in all browsers
> > > > (IE, Firefox, Chrome). Just that in Firefox and Chrome the servlet is
> > > > not physically being called (yet the success method is).
>
> > > > Any help in solving this issue is greatly appreciated.
>
> > > > --Ronen
--
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
