This question already has an answer here:

I am having a problem getting the results back from a WMSGetFeatureInfo call to my GeoServer. Using OpenLayers 2.12, GeoServer 2.4.0, Windows Server2008, and Microsoft IIS 7.5 with Application Request Routing Cache and URL Rewrite. I do NOT use a proxy because I use URL Rewrite. The URL Rewrite takes my incoming requests and formats them to avoid the cross domain/same origin problem.

I have been successfully querying WFS data using this setup for 2 years but when I try to use the WMSGetFeatureInfo it fails.

Here is my process:

  1. I serve multiple WMS layers from GeoServer to my web page.
  2. The user selects a WMS layer from a dropdown. This sets the variable "selLayer" so my WMSGetFeatureInfo call is pointing at the layer the user wants to get information about.
  3. When the user clicks on the layer it fires this code which creates a OpenLayers WMSGetFeatureInfo control with an event listener that should accept the return text & xmlHttp request and display them in a div. :
     var infoControl = new OpenLayers.Control.WMSGetFeatureInfo({
         url: 'http://xx.xx.xx.xx:8080/geoserver/wms',
         title: 'Identify features by clicking',
         layers: [selLayer],
         queryVisible: true,
         //eventListeners: { getfeatureinfo: function (event) { alert("TEXT: " + event.text + ", XY: " + event.xy + ", REQUEST" + event.request + ", FEATURES: " + event.features); } } 
         eventListeners: { getfeatureinfo: function (event) {
             document.getElementById("divAttributes").innerHTML = event.text + "Test Text";
             alert("PUT TEXT HERE!!!");


But, when the script runs I do not get return values for the event.text. When I run this in FireFox (with FireBug) I can copy the GetFeatureInfo request into a new browser window and I get the desired return values.

So my question is: Why am I not getting the return values when I run this on my map webpage but I do get results by posting the request into a new browser window.

marked as duplicate by Ian Turton Jul 30 '17 at 16:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • if you turn up the logging level in geoserver you can see the request being sent in each case? can you see what is different between them? – Ian Turton Oct 10 '13 at 8:38
  • I think you should use Fiddler and compare the raw request content for the OpenLayers request and your paste-into-browser request. You may find that your request headers are slightly different, or comparing the responses (if you even get one) might provide some clues. Also you mention that event.text is not as expected but you don't say whether the event object itself has anything else from the server – tomfumb Nov 9 '13 at 0:18
  • If things work in the console (firefox) but not in a webpage, then cross-origin is my first bet. Have you tried this in chrome with dev toolbar net tab open? That usually warns when there are cross-origin issues – atlefren Feb 26 '14 at 7:11

Why am I not getting the return values when I run this on my map webpage but I do get results by posting the request into a new browser window?

I'm not sure if this can answer your question above, but I had a similar question and problem time ago. At the end I found that the problem was the app serving the features, in this case FeatureServer. It happened that this app wasn't reading correctly the requested feature (in GeoJSON format) and it wasn't parsed correctly to the XMLHttp request (or read it correctly by it).

I'm thinking that you can keep investigating with Firebug, put some breaks with it and check the XMLHttpRequest. The problem could be related to the IIS also, check there also because I read somewhere before people having communication issues between GeoServer and IIS on Windows.

Hope this helps,

  • Thanks Gery, I appreciate you taking the time to look at the issue. I guess I am confused because when I take the XMLHttpRequest from Firebug and paste it into a new browser window it works. If it works in the new window why wouldn't it work in the map window? Both requests are still passed through GeoServer and IIS. – Todd Krueger Oct 9 '13 at 20:39
  • you're welcome Todd, hope I can help you to solve this issue. I'd say that IIS (+ Application Request Routing Cache and URL Rewrite) is not reading correctly what it has been sent, because as you said, things were working correctly for WFS. I think there is a rule of thumb here among people dealing with WFS and WMS (this is a bit general though), when something works with WMS, it doesn't work with WFS, and viceversa. I've read that this especially true for GeoServer running on Windows. – Gery Oct 9 '13 at 20:46
  • I have been dealing with Geoserver WMS and WFS running on Windows since 2006 and that's not my rule of thumb. However, I work with desktop GIS. Web applications tend to be more hard to handle. – user30184 May 20 '14 at 12:31

I ran into something similar a couple of weeks back and enabling CORS took care of it for me. there are step by step instructions here http://enable-cors.org.

this is the advice I recieved:

You may not want to allow cross-domain requests from all hosts, so you could set the value of the Access-Control-Allow-Origin header to the host of your ol3 application instead of '*'. So if your GeoServer runs on myhost.com:8080 and your ol3 app runs on myhost.com:80, your Access-Control-Allow-Origin header's value could be 'myhost.com'


I had a similar problem recently on a project and implemented a proxy in PHP on the main web site to make the WFS query to my Geoserver on another URL. The issue was definitely CORS related ..

Proxy can be see at



I faced the same problem myself and i tried many solutions that discussed here or in other forums and finally i managed to solve the problem of enabling the Cross Origin in Geoserver.

After many trials i discovered that the solution is pretty simple following the exact steps that found in the Jetty webpage Jetty Cross Origin Filter.

But with a small change, the page said that we have to copy the following Cross-Origin filter to the (Web.xml) configuration file, but the solution that worked with me is copying this filter xml configuration in to (webdefault.xml) configuration file, when applying this change the geoserver worked like a charm and i could run any WFS, WMS GetFeatureInfoRequest in JSON format using AJAX instead of using IFrame soultion.

I'm using the following software versions:

  • Boundless OpenGeo v4.5 .
  • Geoserver v 2.6.2 .
  • Jetty v 7.6.13.v20130916 .

Here is the detailed steps:

  1. Download the matched version of the Jetty servlets according to your jetty version from this page Jetty Servlets .
  2. In this example i'm using jetty v7.6.13.v20130916 so the jar file should be named
    (jetty-servlets-7.6.13.v20130916.jar) the filename will be different according to the jetty version - don't change its name because jetty matching the servlet name with its version like :
    jetty-servlets-<%JETTY_VERSION%>.jar, so don't rename it.
  3. Stop the (GeoServer, Postgres) services and Take a copy from the OpenGeo directory located in
    (C:\Program Files (x86)\boundless\OpenGeo) and also Copy the OpenGeo directory located in
    (C:\ProgramData\boundless\OpenGeo) before starting this tutorial, as a precaution step.

  4. Copy the file (jetty-servlets-7.6.13.v20130916.jar) (As-is) into the jetty Lib directory
    (*C:\Program Files (x86)\boundless\OpenGeo\jetty\lib*) also the directory may change according your installation directory.

  5. Copy and paste the following xml lines into the (webdefault.xml) located in
    (C:\Program Files (x86)\boundless\OpenGeo\jetty\ect\webdefault.xml), i'm not sure that the location for these lines to place in the file is important or not but i paste them starting from line #306 after </serlet-mapping>.
  1. Start the (GeoServer, Postgres) services, wait for a few seconds and browse to the geoserver page, the geoserver will start correctly.

This tutorial worked for me and i hope it work for anyone facing the same problem.

  • I noticed that you have used the same answer for two different questions. Should those questions perhaps be flagged as duplicates. Normally every answer here should be unique. – PolyGeo Apr 16 '15 at 8:54
  • I'm just didn't knew that how to referee to my other answer, so i copied it here again. – Ahmed GIS Apr 16 '15 at 10:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.