||It looks like this is a Tomcat-IIS problem rather than a OGC Connector problem. After looking at some other posts here, I tried hand editing the capabilities files, and deleted the DTD references that were at the top of the file.
These were pointing to http://edcw2ks51.cr.usgs.gov/wmsconnector/scheme/wms/1.0.0/capabilities_1_0_0.dtd. When I removed that it worked fine. So, I started testing requests for that particular URL.
The funny thing is that it worked on XP, but not on Windows 2000. It worked going through the Tomcat HTTP connector on both operating systems. It was only through IIS and AJP13 that I was having trouble. After much trial and error, I found that it would work if I did not have periods in the path to the DTD file!
So, that left me with 3 solutions:
- Leave the Tomcat HTTP connector on and change all capabilities files to point to a different port on our server. This requires editing all generated capabilities and adding the port, or setting up some URL forwarding of some sort.
- Edit all generated capabilities and remove the DTD references. Most viewers will probably work without the DTD reference, but we are not sure if this is correct.
- Create copies of the DTD directories and rename them without the period. Then setup URL rewriting (in IIS not Tomcat) that will modify the URL's to use the new directory. I used underscores and an ISAPI rewrite engine from http://www.isapirewrite.com.
I tested all 3 work-arounds and they work. Right now, we are using method 3 because it means we do not have to go in and manually edit all the capabilities files.
Another solution, would be to modify the OGC connectors to allow the adminstrator to specify the location for the DTD's in a parameter. Or change the WMS connector so that it ignores errors retrieving the DTD and dumps the pre-generated capabilities to the client, to let them do any required transformations.