[Mono-bugs] [Bug 81331][Nor] New - SimpleWorkerRequest: Content in subdirs not accesible

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Sat Apr 7 05:29:13 EDT 2007


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gert.driesen at pandora.be.

http://bugzilla.ximian.com/show_bug.cgi?id=81331

--- shadow/81331	2007-04-07 05:29:13.000000000 -0400
+++ shadow/81331.tmp.21524	2007-04-07 05:29:13.000000000 -0400
@@ -0,0 +1,99 @@
+Bug#: 81331
+Product: Mono: Class Libraries
+Version: 1.2
+OS: GNU/Linux [Other]
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: Sys.Web
+AssignedTo: mhabersack at novell.com                            
+ReportedBy: gert.driesen at pandora.be               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: SimpleWorkerRequest: Content in subdirs not accesible
+
+When hosting the ASP.NET runtime in an application (using the 
+SimpleWorkerRequest), then content (either static pages, aspx pages or 
+content procedded by HTTP handlers) in directories relative to the 
+application directory cannot be accessed.
+
+Note:
+
+The syntax for accessing content in relative (virtual) directories 
+differs between .NET 1.1 and 2.0.
+
+In .NET 1.1, MS expects a leading directory separator if the requested 
+page if located in a directory relative to the application dir.
+
+If not, then the following exception is reported:
+
+===
+
+Directory 'C:\bugXXXXX\webdoc' does not exist. Failed to start monitoring 
+file changes.
+
+[HttpException (0x80070002): Directory 'C:\bugXXXXX\webdoc' does not 
+exist. Failed to start monitoring file changes.]
+   System.Web.FileChangesMonitor.FindDirectoryMonitor(String dir, Boolean 
+addIfNotFound, Boolean throwOnError) +527
+   System.Web.FileChangesMonitor.StartMonitoringPath(String alias, 
+FileChangeEventHandler callback) +463
+   System.Web.Caching.CacheDependency.Init(Boolean isPublic, Boolean 
+isSensitive, String[] filenamesArg, String[] cachekeysArg, 
+CacheDependency dependency, DateTime utcStart) +1489
+   System.Web.Caching.CacheDependency..ctor(Boolean isSensitive, String[] 
+filenames, DateTime utcStart) +28
+   System.Web.Configuration.HttpConfigurationSystem.GetCacheDependencies
+(Hashtable cachedeps, DateTime utcStart) +151
+   System.Web.Configuration.HttpConfigurationSystem.ComposeConfig(String 
+reqPath, IHttpMapPath configmap) +654
+   System.Web.HttpContext.GetCompleteConfigRecord(String reqpath, 
+IHttpMapPath configmap) +379
+   System.Web.HttpContext.GetCompleteConfig() +49
+   System.Web.HttpContext.GetConfig(String name) +187
+   System.Web.CustomErrors.GetSettings(HttpContext context, Boolean 
+canThrow) +19
+   System.Web.HttpResponse.ReportRuntimeError(Exception e, Boolean 
+canThrow) +39
+
+   System.Web.HttpRuntime.FinishRequest(HttpWorkerRequest wr, HttpContext 
+contex
+t, Exception e) +486
+
+===
+
+In .NET 2.0, MS does not expect (allow) that leading directory separator 
+character. If you still specify it, then the following error is reported:
+
+===
+
+The resource cannot be found.
+
+Description: HTTP 404. The resource you are looking for (or one of its 
+dependencies) could have been removed, had its name changed, or is te
+mporarily unavailable.  Please review the following URL and make 
+sure that it is spelled correctly.
+
+[HttpException]
+   at 
+System.Web.HttpApplication.ValidatePathExecutionStep.System.Web.HttpApplic
+ation.IExecutionStep.Execute()
+   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, 
+Boolean& completedSynchronously)
+
+===
+
+I've attached a gzipped tar archive containing a repro for this issue, 
+which expects the same behavior as MS.
+
+Part of this repro verifies the behaviour when requesting a page, which 
+is processed by a HTTP handler, from a non-existing (virtual) dir.
+
+On .NET 1.1, this is not possible (same exception, directory does not 
+exist). It works fine on .NET 2.0.
+
+Let me know if you want a separate bug report for this.


More information about the mono-bugs mailing list