By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,067 Members | 1,818 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,067 IT Pros & Developers. It's quick & easy.

Tilde in URL causing stress to custom HttpHandler

P: n/a
We have an .NET 1.1 application running on 4 2K3 load balanced servers
(using WLBS). IIS has the .NET aspnet_isapi.dll mapped as a wildcard
application map. The web.config points *.html to a HttpHandler of our
design. This setup serves over a million page views daily with almost no
hassle whatsoever. We have brought a few affiliates onto our system who
have URLs still floating in Google, Y! and other search engines from before
they moved their domains onto our system. Some of these URLs contain the
tilde character (~) in them. Any time someone finds one of their sites in a
search engine and clicks it, they are presented with an ugly HTTP 500 error.
The error is "Invalid file name for monitoring:
'C:\Inetpub\wwwroot\siteroot\~subfolder'. File names for monitoring must
have absolute paths, and no wildcards."

Does anyone have any insight as to why this is happening? We don't actually
have any physical subdirectories other than /bin and any other subfolder
requests are handled just fine, say oursite.com/test/index.html... that one
works just fine, we don't get any monitoring errors, even though /test/
doesn't really exist.

Thanks for any insight you may be able to provide,
Jared Tullis

Nov 19 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Hi Jared,

Thanks for your posting. As for the
"Invalid file name for monitoring:
'C:\Inetpub\wwwroot\siteroot\~subfolder'. File names for monitoring must
have absolute paths, and no wildcards."

exception you mentioned, it is due to the path validation of the
DirectoryMonitor use by ASP.NET runtime. In fact , the asp.net runtime will
add a FileMonitor (monitoring file changes) for each page which has been
requested( the temporary cached dynamic assembly has been generated for
which) so that when any changes happen on those pages' file, the temporary
cached assembly will be invalid and next regenreate new dynamic compiled
assembly. However, when adding a FileMonitor for a certain given page
path, it'll explicitly check the url path such as :

private FileMonitor AddFileMonitor(string file)
{
.........
if (file.IndexOf('~') != -1)
{
throw FileChangesMonitor.CreateFileMonitoringException(. ...);
}

........

}

that's why if any user click a link contains the "~" char the asp.net will
throw such a invalid path exception.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)




Nov 19 '05 #2

P: n/a
Jared, does a Url with the tilde encoded as %7E cause the same issue? I've
been seeing inconsistencies with the encoding/decoding of spaces v. plus
signs in my HttpModule, which I was able to avoid by forcing space encoding
to %20's.

You -might- be able to get around the problem by using an HttpModule and Url
rewriting rather than the HttpHandler.

The other possibility is that the error is occurring within your
HttpHandler. Tildes are used by ASP.NET to resolve file paths to the
virtual directory. I'd look into that approach first, and do some Tracing
in the Handler to see whether the Url is arriving correctly (or in fact
whether the Handler is getting hit at all).

/// M

"Jared Tullis" <tu*****@noemail.nospam> wrote in message
news:#g**************@TK2MSFTNGP10.phx.gbl...
We have an .NET 1.1 application running on 4 2K3 load balanced servers
(using WLBS). IIS has the .NET aspnet_isapi.dll mapped as a wildcard
application map. The web.config points *.html to a HttpHandler of our
design. This setup serves over a million page views daily with almost no
hassle whatsoever. We have brought a few affiliates onto our system who
have URLs still floating in Google, Y! and other search engines from before they moved their domains onto our system. Some of these URLs contain the
tilde character (~) in them. Any time someone finds one of their sites in a search engine and clicks it, they are presented with an ugly HTTP 500 error. The error is "Invalid file name for monitoring:
'C:\Inetpub\wwwroot\siteroot\~subfolder'. File names for monitoring must
have absolute paths, and no wildcards."

Does anyone have any insight as to why this is happening? We don't actually have any physical subdirectories other than /bin and any other subfolder
requests are handled just fine, say oursite.com/test/index.html... that one works just fine, we don't get any monitoring errors, even though /test/
doesn't really exist.

Thanks for any insight you may be able to provide,
Jared Tullis

Nov 19 '05 #3

P: n/a
v-******@online.microsoft.com (Steven Cheng[MSFT]) confessed in news:x2
#P************@cpmsftngxa10.phx.gbl:
Hi Jared,

Thanks for your posting. As for the
"Invalid file name for monitoring:
'C:\Inetpub\wwwroot\siteroot\~subfolder'. File names for monitoring must
have absolute paths, and no wildcards."

exception you mentioned, it is due to the path validation of the
DirectoryMonitor use by ASP.NET runtime. In fact , the asp.net runtime will add a FileMonitor (monitoring file changes) for each page which has been
requested( the temporary cached dynamic assembly has been generated for
which) so that when any changes happen on those pages' file, the temporary cached assembly will be invalid and next regenreate new dynamic compiled
assembly. However, when adding a FileMonitor for a certain given page
path, it'll explicitly check the url path such as :

private FileMonitor AddFileMonitor(string file)
{
.........
if (file.IndexOf('~') != -1)
{
throw FileChangesMonitor.CreateFileMonitoringException(. ...);
}

........

}

that's why if any user click a link contains the "~" char the asp.net will throw such a invalid path exception.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


Steven,

I understand the essence of your comment, i.e., your explanation of what is
happening, but I am searching for meaning (or I am just being thick
tonight.) I want to know why the design is thus.

So, can you explain: Why is the tilde character special?

First, let me understand: are you saying the code in the runtime that sets
up file monitoring attributes special meaning to the tilde? If so, for what
purpose.

I have also experienced this wierd behavior, when a simple 404 error would
suffice. As a matter of fact, I tried to report this anomaly once, but was
put aback by the fact that I had to *pay* M$ to report a bug on their
website (and maybe they'd refund my money if they deemed it fair)!

Here's what I saw: I have a page called ShoppingCart.aspx compiled into my
app (with associated .cs file, etc.).

If I attempt to load ShoppingCarts.aspx, (typo) the file does not exist and
I get, predictably, a simple 404 error from the framework.

But, if I attempt ~ShoppingCart.aspx (yet another typo) I get the error the
OP is talking about: "File names for monitoring must have absolute paths,
and no wildcards."

Shouldn't the runtime simply emit a 404 FnF error in this case also? Why is
a leading tilde special?

So, please, again: Why, or rather, what is the purpose of excepting the
tilde in this instance?

Here's a naive question: Where is this "feature" documented?

Thanks, in advance.

-- ipgrunt

Nov 19 '05 #4

P: n/a
Thanks for your reply,

Yes, %7E as well as %3F both cause the error. I have seen ng postings
elsewhere that have indicated that the HttpModule would not help in this
situation as they don't get called either.

As for tracing, I attached my debugger, put a Trace.Write in the very first
line of my HttpHandler and this error appears to be occurring before either
is encountered :-(

Our HttpHandler would happily throw a 404 if it could just get its hands on
the request.

"MWells" <outbound__at_sygnal.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Jared, does a Url with the tilde encoded as %7E cause the same issue? I've been seeing inconsistencies with the encoding/decoding of spaces v. plus
signs in my HttpModule, which I was able to avoid by forcing space encoding to %20's.

You -might- be able to get around the problem by using an HttpModule and Url rewriting rather than the HttpHandler.

The other possibility is that the error is occurring within your
HttpHandler. Tildes are used by ASP.NET to resolve file paths to the
virtual directory. I'd look into that approach first, and do some Tracing
in the Handler to see whether the Url is arriving correctly (or in fact
whether the Handler is getting hit at all).

/// M

"Jared Tullis" <tu*****@noemail.nospam> wrote in message
news:#g**************@TK2MSFTNGP10.phx.gbl...
We have an .NET 1.1 application running on 4 2K3 load balanced servers
(using WLBS). IIS has the .NET aspnet_isapi.dll mapped as a wildcard
application map. The web.config points *.html to a HttpHandler of our
design. This setup serves over a million page views daily with almost no hassle whatsoever. We have brought a few affiliates onto our system who
have URLs still floating in Google, Y! and other search engines from before
they moved their domains onto our system. Some of these URLs contain the tilde character (~) in them. Any time someone finds one of their sites

in a
search engine and clicks it, they are presented with an ugly HTTP 500

error.
The error is "Invalid file name for monitoring:
'C:\Inetpub\wwwroot\siteroot\~subfolder'. File names for monitoring must
have absolute paths, and no wildcards."

Does anyone have any insight as to why this is happening? We don't

actually
have any physical subdirectories other than /bin and any other subfolder
requests are handled just fine, say oursite.com/test/index.html... that

one
works just fine, we don't get any monitoring errors, even though /test/
doesn't really exist.

Thanks for any insight you may be able to provide,
Jared Tullis


Nov 19 '05 #5

P: n/a
Hi Steven,

So is there a way to bypass that behavior? There is no use for the
FileMonitor since there is no physical path. Maybe this already is or could
be addressed in .NET 2.0? Our HttpHandler would handle the request without
issue if it could just get its hands on the request, but this is happening
before the HttpHandler even gets a chance to weigh in. At least it could
throw a 404 like IPGrunt suggests below so the user isn't totally thrown.
Please let me know if I can bypass this.

Thanks,
Jared

"IPGrunt" <me@privacy.net> wrote in message
news:Xn**********************************@130.133. 1.4...
v-******@online.microsoft.com (Steven Cheng[MSFT]) confessed in news:x2
#P************@cpmsftngxa10.phx.gbl:
Hi Jared,

Thanks for your posting. As for the
"Invalid file name for monitoring:
'C:\Inetpub\wwwroot\siteroot\~subfolder'. File names for monitoring must
have absolute paths, and no wildcards."

exception you mentioned, it is due to the path validation of the
DirectoryMonitor use by ASP.NET runtime. In fact , the asp.net runtime will
add a FileMonitor (monitoring file changes) for each page which has been
requested( the temporary cached dynamic assembly has been generated for
which) so that when any changes happen on those pages' file, the

temporary
cached assembly will be invalid and next regenreate new dynamic compiled
assembly. However, when adding a FileMonitor for a certain given page
path, it'll explicitly check the url path such as :

private FileMonitor AddFileMonitor(string file)
{
.........
if (file.IndexOf('~') != -1)
{
throw FileChangesMonitor.CreateFileMonitoringException(. ...); }

........

}

that's why if any user click a link contains the "~" char the asp.net

will
throw such a invalid path exception.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


Steven,

I understand the essence of your comment, i.e., your explanation of what

is happening, but I am searching for meaning (or I am just being thick
tonight.) I want to know why the design is thus.

So, can you explain: Why is the tilde character special?

First, let me understand: are you saying the code in the runtime that sets
up file monitoring attributes special meaning to the tilde? If so, for what purpose.

I have also experienced this wierd behavior, when a simple 404 error would
suffice. As a matter of fact, I tried to report this anomaly once, but was
put aback by the fact that I had to *pay* M$ to report a bug on their
website (and maybe they'd refund my money if they deemed it fair)!

Here's what I saw: I have a page called ShoppingCart.aspx compiled into my
app (with associated .cs file, etc.).

If I attempt to load ShoppingCarts.aspx, (typo) the file does not exist and I get, predictably, a simple 404 error from the framework.

But, if I attempt ~ShoppingCart.aspx (yet another typo) I get the error the OP is talking about: "File names for monitoring must have absolute paths,
and no wildcards."

Shouldn't the runtime simply emit a 404 FnF error in this case also? Why is a leading tilde special?

So, please, again: Why, or rather, what is the purpose of excepting the
tilde in this instance?

Here's a naive question: Where is this "feature" documented?

Thanks, in advance.

-- ipgrunt

Nov 19 '05 #6

P: n/a
Hi Jared,

Thanks for your followup. Ok, I'll try consulting some further experts
(ASPNET or iis) to see whether there is any means to workaround this at
asp.net or IIS level. I'll update you when I got any update. Thanks for
your understanding.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 19 '05 #7

P: n/a
v-******@online.microsoft.com (Steven Cheng[MSFT]) confessed in
news:MH**************@cpmsftngxa10.phx.gbl:
Hi Jared,

Thanks for your followup. Ok, I'll try consulting some further experts
(ASPNET or iis) to see whether there is any means to workaround this at
asp.net or IIS level. I'll update you when I got any update. Thanks for
your understanding.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


I'd sure like to know why and what to do about it also. (same problem at
times, moving linux/unix to IIS).

-- ipgrunt

Nov 19 '05 #8

P: n/a
Hi ,

Seems this problem has be a by design( the dev guys did found the problem )
issue, the asp.net will use the "~" to represent the application root , so
any url contains this will cause the invalid path exception. Also,
currently seems there hasn't been any good approach to workaround this. If
we do need to avoid this, you may need to contact the MS PSS for a single
hotfix.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 19 '05 #9

P: n/a
v-******@online.microsoft.com (Steven Cheng[MSFT]) confessed in
news:xa**************@cpmsftngxa10.phx.gbl:
Hi ,

Seems this problem has be a by design( the dev guys did found the problem )
issue, the asp.net will use the "~" to represent the application root , so
any url contains this will cause the invalid path exception. Also,
currently seems there hasn't been any good approach to workaround this. If
we do need to avoid this, you may need to contact the MS PSS for a single
hotfix.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


Dumb, really dumb!

Maybe M$ folks that write web server code ought to see how users web apps
have deployed with the competition's products? Especially when M$ marketing
folks work hard to convice us 'grandfathered' users to switch over to M$
stuff.

Thanks Steve for following up. Your work is superb!

-- ipgrunt

Nov 19 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.