[Mono-bugs] [Bug 371859] request to Web services does not work (in 2.0 profile?)

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Thu Apr 10 10:03:49 EDT 2008


User mhabersack at novell.com added comment

--- Comment #3 from Marek Habersack <mhabersack at novell.com>  2008-04-10 08:03:49 MST ---
I can't reproduce the 404 problem - it works fine for me with svn trunk.

As for the proposed patch - I don't think it's acceptable. There are several
reasons for that;

1. 2.0 should always use the BuildManager to build assemblies/types and only
virtual paths can be used to refer to resources.

2. Parsing files from arbitrary physical paths in
PageParser.GetCompiledPageInstance may pose a security threat. 

3. As per
the inputFile parameter is supposed to point to the physical path referred to
by the virtualPath parameter (or it may be null, as you note) so, by extension,
it can be ignored if it isn't needed (and it's not in the 2.0+ profiles)

I agree the fake virtual path hack should be removed, but there is little we
can do here, since the help generator lives outside any application's tree.
There are two solutions I can see at this point:

1. [not much better than the current hack, imo] Put the helper generator page
inside system.web.dll as a resource and use a special virtual path to retrieve
the file from the resources.

2. Provide a BuildProvider (inside System.Web.Services.dll) which would load
the helper from anywhere (including the dll resources) suitable and return the
compiled type. The BuildProvider could even live inside System.Web.dll, if we
made System.Web.Services.dll a friend assembly (via InternalsVisibleTo
attribute) to System.Web.dll - then it could derive from the internal

What do you think, Atsushi?

Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the mono-bugs mailing list