DeMarco, Alex wrote:
...
OK Well thanks for the list etiquette lesson.
Apart from the top-posting, it was not so much about list etiquette, as about expressing
yourself precisely, so as to save some time to the people trying to help you.
When you say "my desktop", it is confusing, because you have a "my desktop" also when you
are working directly on the webserver host. When you show a sample URL with a space in
the middle and you say "it doesn't work", we are left to wonder what doesn't work or why.
Isolated, any one of these things can be overcome, but when you pile up 5 things like that
in the same message, it is getting hard to figure out what is what.
Basically, you want to be helped, and there are people here prepared to help.
But if these people think that they'll have to spend 20 minutes first to ask you to
correct typos or explain precisely what you mean by "it fails", they will get discouraged
and leave your message to be answered later, or by someone else.
The result is that you get no answer, or get it later.
So, be nice to yourself.
...
When I call the url via IE directly on the webserver a log entry appears in the redirector
log and the web service listing comes up correctly.
Allright. That means that, when given a "correct" URL to fetch, IIS and Isapi_redirector
and Tomcat do their job properly. By extrapolation, neither IIS nor Isapi_redirector nor
Tomcat are "refusing" that URL with "/myapp/services" in it.
Yet when I call the same URL from my (own workstation's) desktop no entry
appears in the log and IIS returns a 404 as shown in firebug.
By extrapolation again, it must be that when you do this from your own workstation,
something happens to that URL, before it gets to IIS, that results in :
- IIS + isapi_redirector not recognising that this URL matches one of the URL parts
mentioned in the uriworkermap
- so they do not forward it to Tomcat
- in consequence, IIS is trying to serve it itself
- and IIS does not find "/myapp/services" (or whatever it has become) in its own URL space
(e.g. under wwwroot), so it returns a 404 Not Found.
Now what happens to the URL, is for you to find out. Firebug is a good option, if you
really check what is the complete dialog before you get the 404 error.
It may be some re-direct, as mentioned by Rainer earlier.
Check in Firebug if between the original request, and the 404, there is any 302 response
coming back. If there is, then check what that 302 response says in its "Location:" header.
Maybe for example it says "http://localhost/....";. That would work when you are on the
webserver itself, but fail when you are on your workstation. (And it would fail with a
404 error if you also have IIS running on your workstation; if you don't have IIS running,
then it should fail with some other error status.)
In Firebug, there must be a way to copy a request/response sequence to the clipboard. If
so, do that and paste it here. We might spot something you don't.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
