Hi All,

Working in ASP.Net 2.0, session state set to cookieless. We recently
updated the application from a 1.1 project. We've always run with
cookieless sessions. Since the upgrade to 2.0, we keep getting lots of
similar errors. Our error reporting gives us a message like:

Time: [14/03/2008 11:44]
Application Version: [2.0.0014.0]
Message: [The file '/Application/(s(oqe1gv45d4gxfy45ee1ateuh))/
start.aspx' does not exist.]
Source: [System.Web]
TargetSite: [Void CheckVirtualFileExists(System.Web.VirtualPath)]
StackTrace:
BEGIN
at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath
virtualPath)
at
System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath
virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
allowBuildInPrecompile)
at
System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext
context, VirtualPath virtualPath, Boolean noBuild, Boolean
allowCrossApp, Boolean allowBuildInPrecompile)
at
System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath
virtualPath, HttpContext context, Boolean allowCrossApp, Boolean
noAssert)
at
System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath
virtualPath, Type requiredBaseType, HttpContext context, Boolean
allowCrossApp, Boolean noAssert)
at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext
context, String requestType, VirtualPath virtualPath, String
physicalPath)
at
System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext
context, String requestType, VirtualPath virtualPath, String
physicalPath)
at System.Web.HttpApplication.MapHttpHandler(HttpContext context,
String requestType, VirtualPath path, String pathTranslated, Boolean
useAppConfig)
at
System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean& completedSynchronously) END

Now, if I go and look at the IIS logs, we can have something like:

2008-03-14 11:44:55 255.255.255.255 GET /Application/themes/main/css/
clientstyles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE
+7.0;+Windows+NT+5.1;+InfoPath.1)
https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
200
2008-03-14 11:44:56 255.255.255.255 GET /Application/themes/main/css/
styles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows
+NT+5.1;+InfoPath.1) https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
200
2008-03-14 11:44:56 255.255.255.255 GET /Application/scripts/
Help_Util_Validation.js - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE
+7.0;+Windows+NT+5.1;+InfoPath.1)
https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
200
2008-03-14 11:44:56 255.255.255.255 GET /Application/
(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx hp=3 443 - 0.0.0.0 - - 302

So it looks like someone, in the middle of their session is suddenly
putting a request through that isn't having the Session ID stripped -
and hence the directory being requested doesn't exist, hence the
ASP.Net error I notice also, in this case, that the User Agent had
disappeared on this request. I don't believe (but will have to go
searching) that this was true in the other cases I've seen, so may not
be an issue.

So what should I look for next? Are there circumstances where the
ISAPI dll would fail to strip the Session ID? Or some other place I
should be looking?

TIA,
Damien

It seems to me that capital 'S' and lower case 's' makes a difference.
All good requests have a capital 'S' in a beginning of the SessionID
/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3

The only bad request has a lower case 's'
/Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx


You can reverse IP address it came from. Most likely it came from "bad"
robot. "Bad" in terms of poorly written. That converts URLs to lower case
at will...

Second option is that someone has published link to your site somewhere with
a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo
trying to follow that link....

Solution: do not pay attention


George.


"Damien" <(E-Mail Removed)> wrote in message
news:095802d3-1daa-4fa8-8e2b-(E-Mail Removed)...
> Hi All,
>
> Working in ASP.Net 2.0, session state set to cookieless. We recently
> updated the application from a 1.1 project. We've always run with
> cookieless sessions. Since the upgrade to 2.0, we keep getting lots of
> similar errors. Our error reporting gives us a message like:
>
> Time: [14/03/2008 11:44]
> Application Version: [2.0.0014.0]
> Message: [The file '/Application/(s(oqe1gv45d4gxfy45ee1ateuh))/
> start.aspx' does not exist.]
> Source: [System.Web]
> TargetSite: [Void CheckVirtualFileExists(System.Web.VirtualPath)]
> StackTrace:
> BEGIN
> at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath
> virtualPath)
> at
> System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath
> virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
> allowBuildInPrecompile)
> at
> System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext
> context, VirtualPath virtualPath, Boolean noBuild, Boolean
> allowCrossApp, Boolean allowBuildInPrecompile)
> at
> System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath
> virtualPath, HttpContext context, Boolean allowCrossApp, Boolean
> noAssert)
> at
> System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath
> virtualPath, Type requiredBaseType, HttpContext context, Boolean
> allowCrossApp, Boolean noAssert)
> at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext
> context, String requestType, VirtualPath virtualPath, String
> physicalPath)
> at
> System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext
> context, String requestType, VirtualPath virtualPath, String
> physicalPath)
> at System.Web.HttpApplication.MapHttpHandler(HttpContext context,
> String requestType, VirtualPath path, String pathTranslated, Boolean
> useAppConfig)
> at
> System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
> at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
> Boolean& completedSynchronously) END
>
> Now, if I go and look at the IIS logs, we can have something like:
>
> 2008-03-14 11:44:55 255.255.255.255 GET /Application/themes/main/css/
> clientstyles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE
> +7.0;+Windows+NT+5.1;+InfoPath.1)
> https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
> 200
> 2008-03-14 11:44:56 255.255.255.255 GET /Application/themes/main/css/
> styles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows
> +NT+5.1;+InfoPath.1)
> https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
> 200
> 2008-03-14 11:44:56 255.255.255.255 GET /Application/scripts/
> Help_Util_Validation.js - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE
> +7.0;+Windows+NT+5.1;+InfoPath.1)
> https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
> 200
> 2008-03-14 11:44:56 255.255.255.255 GET /Application/
> (s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx hp=3 443 - 0.0.0.0 - - 302
>
> So it looks like someone, in the middle of their session is suddenly
> putting a request through that isn't having the Session ID stripped -
> and hence the directory being requested doesn't exist, hence the
> ASP.Net error I notice also, in this case, that the User Agent had
> disappeared on this request. I don't believe (but will have to go
> searching) that this was true in the other cases I've seen, so may not
> be an issue.
>
> So what should I look for next? Are there circumstances where the
> ISAPI dll would fail to strip the Session ID? Or some other place I
> should be looking?
>
> TIA,
> Damien
>
>

most likely its an expired session, so a redirect is done for the new
session. an empty user agent is usually a bot.

-- bruce (sqlwork.com)


"Damien" wrote:

> Hi All,
>
> Working in ASP.Net 2.0, session state set to cookieless. We recently
> updated the application from a 1.1 project. We've always run with
> cookieless sessions. Since the upgrade to 2.0, we keep getting lots of
> similar errors. Our error reporting gives us a message like:
>
> Time: [14/03/2008 11:44]
> Application Version: [2.0.0014.0]
> Message: [The file '/Application/(s(oqe1gv45d4gxfy45ee1ateuh))/
> start.aspx' does not exist.]
> Source: [System.Web]
> TargetSite: [Void CheckVirtualFileExists(System.Web.VirtualPath)]
> StackTrace:
> BEGIN
> at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath
> virtualPath)
> at
> System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath
> virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
> allowBuildInPrecompile)
> at
> System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext
> context, VirtualPath virtualPath, Boolean noBuild, Boolean
> allowCrossApp, Boolean allowBuildInPrecompile)
> at
> System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath
> virtualPath, HttpContext context, Boolean allowCrossApp, Boolean
> noAssert)
> at
> System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath
> virtualPath, Type requiredBaseType, HttpContext context, Boolean
> allowCrossApp, Boolean noAssert)
> at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext
> context, String requestType, VirtualPath virtualPath, String
> physicalPath)
> at
> System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext
> context, String requestType, VirtualPath virtualPath, String
> physicalPath)
> at System.Web.HttpApplication.MapHttpHandler(HttpContext context,
> String requestType, VirtualPath path, String pathTranslated, Boolean
> useAppConfig)
> at
> System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
> at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
> Boolean& completedSynchronously) END
>
> Now, if I go and look at the IIS logs, we can have something like:
>
> 2008-03-14 11:44:55 255.255.255.255 GET /Application/themes/main/css/
> clientstyles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE
> +7.0;+Windows+NT+5.1;+InfoPath.1)
> https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
> 200
> 2008-03-14 11:44:56 255.255.255.255 GET /Application/themes/main/css/
> styles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows
> +NT+5.1;+InfoPath.1) https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
> 200
> 2008-03-14 11:44:56 255.255.255.255 GET /Application/scripts/
> Help_Util_Validation.js - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE
> +7.0;+Windows+NT+5.1;+InfoPath.1)
> https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
> 200
> 2008-03-14 11:44:56 255.255.255.255 GET /Application/
> (s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx hp=3 443 - 0.0.0.0 - - 302
>
> So it looks like someone, in the middle of their session is suddenly
> putting a request through that isn't having the Session ID stripped -
> and hence the directory being requested doesn't exist, hence the
> ASP.Net error I notice also, in this case, that the User Agent had
> disappeared on this request. I don't believe (but will have to go
> searching) that this was true in the other cases I've seen, so may not
> be an issue.
>
> So what should I look for next? Are there circumstances where the
> ISAPI dll would fail to strip the Session ID? Or some other place I
> should be looking?
>
> TIA,
> Damien
>
>
>

On Mar 14, 3:23*pm, "George Ter-Saakov" <gt-...@cardone.com> wrote:
> It seems to me that capital 'S' and lower case 's' makes a difference.
> All good requests have a capital 'S' in a beginning of the SessionID
> /Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
>
> The only bad request has a lower case 's'
> /Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx
>
Thanks for spotting that. I'll have to go back and check I didn't just
screw that up while anonymising the post, but you're right, it does
look different.

> You can reverse IP address it came from. Most likely it came from "bad"
> robot. "Bad" in terms of *poorly written. That converts URLs to lower case
> at will...
>
> Second option is that someone has published link to your site somewhere with
> a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo
> trying to follow that link....
>
I know that we do have some links from elsewhere that may have these
things. It would help a lot if bots would set the Referer header (so
we could find the duff sites and let the owners know)

> Solution: do not pay attention
>
> George.
>
Thanks George. Not paying attention is a good strategy, but our error
reporting sends messages to our helpdesk, who raise incidents, that I
have to close and give reasons on :-( I can try to get our error
reporting system to ignore these errors specifically, but it'll mean
having to pull apart exception messages to find what path is being
accessed :-(

My website sends me an email every time unexpected exception happens too.
I just learned to ignore those messages. If some BOT gives me to many errors
I just ban it's IP address...

I guess you will have to do the same to avoid to many fake incidents from
help desk

George.


"Damien" <(E-Mail Removed)> wrote in message
news:061e0b29-6aea-448a-aea8-(E-Mail Removed)...
On Mar 14, 3:23 pm, "George Ter-Saakov" <gt-...@cardone.com> wrote:
> It seems to me that capital 'S' and lower case 's' makes a difference.
> All good requests have a capital 'S' in a beginning of the SessionID
> /Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
>
> The only bad request has a lower case 's'
> /Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx
>
Thanks for spotting that. I'll have to go back and check I didn't just
screw that up while anonymising the post, but you're right, it does
look different.

> You can reverse IP address it came from. Most likely it came from "bad"
> robot. "Bad" in terms of poorly written. That converts URLs to lower case
> at will...
>
> Second option is that someone has published link to your site somewhere
> with
> a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo
> trying to follow that link....
>
I know that we do have some links from elsewhere that may have these
things. It would help a lot if bots would set the Referer header (so
we could find the duff sites and let the owners know)

> Solution: do not pay attention
>
> George.
>
Thanks George. Not paying attention is a good strategy, but our error
reporting sends messages to our helpdesk, who raise incidents, that I
have to close and give reasons on :-( I can try to get our error
reporting system to ignore these errors specifically, but it'll mean
having to pull apart exception messages to find what path is being
accessed :-(

On Mar 17, 8:44*am, Damien <Damien_The_Unbelie...@hotmail.com> wrote:
> On Mar 14, 3:23*pm, "George Ter-Saakov" <gt-...@cardone.com> wrote:> It seems to me that capital 'S' and lower case 's' makes a difference.
> > All good requests have a capital 'S' in a beginning of the SessionID
> > /Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3
>
> > The only bad request has a lower case 's'
> > /Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx
>
> Thanks for spotting that. I'll have to go back and check I didn't just
> screw that up while anonymising the post, but you're right, it does
> look different.
>
I've now verified that it does seem to be dropping everything into
lowercase. (So when I anonymised, I should have had "application")

> > You can reverse IP address it came from. Most likely it came from "bad"
> > robot. "Bad" in terms of *poorly written. That converts URLs to lower case
> > at will...
>
> > Second option is that someone has published link to your site somewhere with
> > a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo
> > trying to follow that link....
>
> I know that we do have some links from elsewhere that may have these
> things. It would help a lot if bots would set the Referer header (so
> we could find the duff sites and let the owners know)
>

I've now further analysed the ones that seem to fall into this
pattern. I don't think it's a bot, because it can happen even quite
late on in our sequential process. But the following seems to be one
pattern:

Client does a GET on a particular aspx page, gets a good response.
Resources for that page (CSS, JS, Images) then get loaded. Then
there's the weird request for the page again, all in lowercase. No
User Agent, no Referer. Then, usually, the client goes on to do a
postback on the page. So it looks like the second request (the one in
lowercase) isn't necessarily being shown to the user. Is there some
kind of popup-blocker, security software or something similar that
might perform additional requests to URLs like this?

I honestly don't know what to look at next. Problem is, our error
system is fairly aggressive, and after an error occurs, the session
gets abandoned. So the subsequent postback can't be dealt with nicely
anyway.

Thanks in advance again, and thanks again to George and Bruce for
helping me make some sense of this.

Damien