|
Home > Archive > IIS Server > November 2004 > IIS 6 serving invalid URLs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IIS 6 serving invalid URLs
|
|
| Kevin Acker 2004-11-02, 5:54 pm |
| We recently put a Windows 2003 web server into production and have
discovered that it is serving invalid URLs. For example, the real URL
for a web page on the server is http://servername/default.htm but for
whatever reason the server will still serve the default.htm page even
if the URL sent to the server is
http://servername/default.htm/garba...lah/nogood.htm. It seems
that IIS 6 is just ignoring the rest of the URL after the page name,
in this case default.htm, and serving up the content. This is causing
a problem for the software we use to index our site as it is seeing
millions of invalid URLs. This same behavior did not occur under IIS
5 as IIS 5 returned a 404 error message. Does anyone know of a way we
could turn this off so the invalid URL returns a 404 message rather
than the default.htm web page? Thanks much!
| |
| Jorge Oblitas 2004-11-02, 5:54 pm |
| Just a crazy idea: COuld you check if someone made a change in your custom
error messages to send default.htm as the default error page for 404 errors?
Jorge
"Kevin Acker" <kevin.acker@dwd.state.wi.us> escribió en el mensaje
news:e23eb869.0411020740.37e4bf04@posting.google.com...
> We recently put a Windows 2003 web server into production and have
> discovered that it is serving invalid URLs. For example, the real URL
> for a web page on the server is http://servername/default.htm but for
> whatever reason the server will still serve the default.htm page even
> if the URL sent to the server is
> http://servername/default.htm/garba...lah/nogood.htm. It seems
> that IIS 6 is just ignoring the rest of the URL after the page name,
> in this case default.htm, and serving up the content. This is causing
> a problem for the software we use to index our site as it is seeing
> millions of invalid URLs. This same behavior did not occur under IIS
> 5 as IIS 5 returned a 404 error message. Does anyone know of a way we
> could turn this off so the invalid URL returns a 404 message rather
> than the default.htm web page? Thanks much!
| |
|
|
|
|
| David Wang [Msft] 2004-11-03, 2:48 am |
| I cannot reproduce your claim.
Static file handler is not going to allow PathInfo (that's the term for the
"extra junk" you are adding), so I suspect you've got something ELSE
configured on the server (possibly *-scriptmapped) which is causing this
change in behavior. ISAPI DLLs can change IIS behavior in whatever way it
wants.
Please give your App Mapping for the * and .htm extensions as well as any
ISAPI Filters installed on the server.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Kevin Acker" <kevin.acker@dwd.state.wi.us> wrote in message
news:O2WgllPwEHA.1988@TK2MSFTNGP12.phx.gbl...
No, the 404 error is still set to re-direct people to the default
location, C:\WINDOWS\help\iisHelp\common\404b.htm. The same problem
occurs if we request any web page on the server. Another example: If
the URL sent is
http://servername/virtualdirectory/...arbage/junk.htm
the server will actually serve the URL
http://servername/virtualdirectory/test.htm. Thanks again for the help.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
| |
| Kevin Acker 2004-11-03, 7:48 am |
| I've figured out what is causing this to happen but don't understand
why. Due to the way our Frontpage users create web pages we've been
forced to set the .htm file extension to be processed by the ssinc.dll.
Within IIS we have the .htm extension mapped to
C:\WINDOWS\system32\inetsrv\ssinc.dll. If I remove this mapping then
the server will return a 404 if an invalid URL is sent to it. Mapping
the .htm extension to the ssinc.dll under IIS 5 did not cause this
behavior. While it's probably not a great practice to map the .htm
extension to the ssinc.dll it looks like this is a bug, i.e. it should
still not be serving invalid URLs. I can't remove this mapping at this
time in production, since all of our Frontpage generated content would
fail to display correctly, so if anyone has any ideas on how to work
around this it would be much appreciated. Thanks.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
| |
| David Wang [Msft] 2004-11-04, 2:46 am |
| FYI: The issue is not that IIS6 is serving "invalid URLs". The parts of
the URL that you call "invalid" is actually called PathInfo -- and
executables/scriptmapped extensions are allowed to process PathInfo however
it wishes. In fact, your "invalid URL" is exactly how CGI works -- so it is
FAR from being "invalid".
For example, this is a valid URL:
http://server/isapi.dll/PathInfo.ht...asp?Query=Value
/isapi.dll is processed, with a PathInfo of /PathInfo.htm/MorePathInfo.asp
The only work-around I can think of for your case is to scriptmap .htm to
ASP.DLL instead of SSINC.DLL. You lose no functionality since ASP is also
able to do most server-side include functionality, it can handle HTML, and
it sends back 404 in the cases you point out. You are not losing any
performance because ssinc.dll turns off response caching of static files
already (like .htm) -- while on the contrary, ASP will do output caching, so
you gain performance.
Other choices include:
1. Do not map .htm to ssinc.dll
2. Open support case with Microsoft PSS to get a QFE.
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Kevin Acker" <kevin.acker@dwd.state.wi.us> wrote in message
news:eIA40AbwEHA.1400@TK2MSFTNGP11.phx.gbl...
I've figured out what is causing this to happen but don't understand
why. Due to the way our Frontpage users create web pages we've been
forced to set the .htm file extension to be processed by the ssinc.dll.
Within IIS we have the .htm extension mapped to
C:\WINDOWS\system32\inetsrv\ssinc.dll. If I remove this mapping then
the server will return a 404 if an invalid URL is sent to it. Mapping
the .htm extension to the ssinc.dll under IIS 5 did not cause this
behavior. While it's probably not a great practice to map the .htm
extension to the ssinc.dll it looks like this is a bug, i.e. it should
still not be serving invalid URLs. I can't remove this mapping at this
time in production, since all of our Frontpage generated content would
fail to display correctly, so if anyone has any ideas on how to work
around this it would be much appreciated. Thanks.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
| |
| Kevin Acker 2004-11-04, 7:48 am |
|
Thanks for the background on the PathInfo piece. I tried to map the
.htm extension to the asp.dll but due to the way the Frontpage users are
doing includes, they are using file includes rather than virtual
includes, the asp.dll mapping will not work. It sounds like I'm going
to need to open a case since it still doesn't sound like the ssinc.dll
is working correctly if the asp.dll returns a 404 when the pathinfo
statement is invalid and the ssinc.dll does not and it used to work the
same under IIS 5. Thanks again for your assistance.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|
|
|
|
|