Ajax.Request - can't get to work in Firefox, Chrome
Ronen
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
Guillaume Lepicard
--
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-s...@googlegroups.com.
To unsubscribe from this group, send email to prototype-scripta...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
Ronen
both firefox and chrome, but still no luck.
--Ronen
On Mar 13, 4:14 am, Guillaume Lepicard <guillaume.lepic...@gmail.com>
wrote:
> hi ronen,
> could it be a browser cache issue ? have you tried clearing cache before
> running ajax ?
>
> > prototype-scripta...@googlegroups.com<prototype-scriptaculous%2Bunsu...@googlegroups.com>
disccomp
T.J. Crowder
> 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 / com
www.crowdersoftware.com
Ronen
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.
Scott
assumes that they were caching issues. With the method as 'post' and
adding the current date and time in the parameters field (or query
string), I've been able to get past this issue.
This is to make sure the url being called is alway unique. You may
want to parse out punctuation characters though.
I would be interested to know if this is some sort of application
scope issue like T.J. Crowder is suggesting. It seems unlikely due to
the fact that IE is allowing it. Although I have seen IE do some
pretty weird stuff I wouldn't ignore the possibility.
Ronen
I've tried to add the current timestamp (via the javascript expression
"new Date().getTime()" ) to the parameters and the query string (in
all the combinations such as first adding it only to parameters, then
only to query string, and then to both) and unfortunately, still no
luck.
I did verify that in IE, the timestamp was being received by the
servlet.
One thing I did catch, however, is that the first time I tried it in
firefox, firebug reported this exception:
Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIXMLHttpRequest.send
This was thrown by the line
this.transport.send()
of prototype.js, but subsequent times, firefox did not produce this
exception anymore (the ajax request did not raise any exceptions, yet
still no luck in reaching the servlet)
I looked this error code up on google and also tried looking it up on
Mozilla's Source Code site (http://mxr.mozilla.org/mozilla1.8.0/source/
extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1423) and it looks
like this NS_ERROR_FAILURE error is returned by the send() method in
three places:
Line 1429 (this is the case where more than one request is made with
the same XMLHttpRequest object)
Line 1553 (not quite sure how this one works)
Line 1626 (right before firefox returns a successful response, it
check whether mChannel exists, and if not, it returns this error).. my
guess would be that this is the line that's causing my request not to
work, but I can't figure out why.
--Ronen
disccomp
creating a small self-contained minimum test case which fails. Using a
relative URL ensures that it is from the same origin as the loading
page. -Mark
T.J. Crowder
> 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!
[4] http://en.wikipedia.org/wiki/Same_origin_policy
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
T.J. Crowder
> 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,
>
> [1]http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServlet....)
Ronen
In my servlet, I overrided the doOptions() method from HttpServlet and
returned the response headers that you suggested:
> 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"));
and Firefox and Chrome both started working beautifully (also verified
that IE still works).
In the end, my overall intent is to package this HTML file with my web
application, so it sounds like I won't need to have this doOptions()
in my servlet. It's just that in the beginning, I figured I would
test the HTML file outside of the web app and I guess I didn't realize
I would run into this kind of trouble. Still, it's always good to
know how to go about fixing something like this in the future.
Thanks for everyone's help.
--Ronen