In response to my post Why runat="server" for ASP.NET?, Talbott Crowell tried of Microsoft National Services tried to comment but got an error from dasBlog. I’ve decided to post his emailed comments here:
I understand your point, but the importance of [runat="server"] is more for consistancy and extensibility. If the developer has to mark some tags some ways (ie an [<asp:] a ignore to ASP.NET tell otherwise difficult be would it tags, the of one with collision name has future agent user some if What engine. by parsed needs what and Response.Write as directly sent is simplifies this Also, confusion. more creates then runat, using cases other in prefix)
To which I replied:
I was suggesting all tags would default to [runat=server], and for those that must not run at server, then the developer would use [runat=client].
To which Talbot replied:
If [runat=client] was required for all client-side tags, the parser would need to parse all tags and strip out the [runat=client] part. Currently, if my guess is correct, the parser simply ignores all text (tags or no tags) unless it is a tag with the [runat=server] attribute or a “<%” prefix or ssi “<!– #include…
And:
Also, since ASP.NET is designed to allow separation of the web designers (foo.aspx) from the web developers (foo.aspx.vb), the web designers can use their own web designer tools to place HTML and client-side JavaScript without having to know about ASP.NET specific tags or attributes.
Which ends our email conversation that was forced by the error Talbot got when trying to comment on my blog. Bringing it back online I respond with:
What would be the problem with the parser having to parse all tags? Unless I misunderstand, it only parses once after every time the file is changed, and from then on runs the compiled version.
And:
I do understand that conceptually ASP.NET allows separation of design and development, which I personally think is of dubious benefit. You say that ASP.NET allows web designers to use their own web designer tools to place HTML and client-side JavaScript without having to know about ASP.NET specific tags or attributes, yet don’t they have to know about [<asp:] and [runat=server]? What is the difference in that and having to know about [runat=client]? Better yet, why not create pass-thru server-side equivalents of all common HTML tags?
Reasons I really don’t like [runat=server] include it forces markup to be a lot more verbose than it already is requiring lots of left-right scrolling or up-down scrolling, and it trips me up with run-time errors when I forget to include it, as do semi-colons in C#. Why have something required for the normal case? Why can’t the normal case be simplier and the default? BTW, I’d be happy with a directive at the top of the page that sets the default explicitly so that the default would not be hidden in configuration somewhere.
Oh, and as for the “dubious benefit“ statement, that deserves a future full and complete blog essay…
So let the comments continue…(And thanks Talbot for your comments)
In response to my post Why runat="server" for ASP.NET?, Talbott Crowell of Microsoft National Services tried to post the following comment:
I understand your point, but the importance of [runat="server"] is more for consistancy and extensibility. If the developer has to mark some tags some ways (ie an [<asp:] prefix) and in other cases using runat, then it creates more confusion. Also, this simplifies what is sent directly to the user agent as a Response.Write and what needs to be parsed by the ASP.NET engine. What if some user agent of the future has a name collision with one of the ASP.NET tags, it would be difficult otherwise to tell ASP.NET to ignore a tag.
However he got an error. After I set <customErrors mode="Off"/> he was able to provide me with the following error information:
Server Error in '/Mikes' Application.
——————————————————————————–
A potentially dangerous Request.Form value was detected from the client (_ctl2:comment="…s (ie an [<asp:] prefix) and i…").
Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.
Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (_ctl2:comment="…s (ie an [<asp:] prefix) and i…").
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[HttpRequestValidationException (0×80004005): A potentially dangerous Request.Form value was detected from the client (_ctl2:comment="…s (ie an [<asp:] prefix) and i…").]
System.Web.HttpRequest.ValidateString(String s, String valueName, String collectionName) +230
System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, String collectionName) +99
System.Web.HttpRequest.get_Form() +113
System.Web.UI.Page.GetCollectionBasedOnMethod() +69
System.Web.UI.Page.DeterminePostBackMode() +47
System.Web.UI.Page.ProcessRequestMain() +2106
System.Web.UI.Page.ProcessRequest() +216
System.Web.UI.Page.ProcessRequest(HttpContext context) +18
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +179
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +87
——————————————————————————–
Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573
Talbot thinks it was the "<asp:" that caused the error. I don’t have the skills yet to debug this reasonably quickly in the dasBlog code; does anyone know?
Also, I don’t mean to look a gift horse in the mouth, but isn’t this something dasBlog should handle more gracefully? (i.e. I’m not faulting a program that is free, but instead discussing what would be the ideal design.) Or not because of it being a potential security hole?
As for Talbot’s response to my original question, I’ll post a clarification next to my question next.
One of the things I don’t like about ASP.NET is [runat=”server”]. Why can’t we set [runat=”server”] to be the default for certain tags? After all, isn’t every tag that starts with “<asp:” run at the server? Why make me bloat code? Why put something there I might forget to type and then waste my time figuring out while debugging?
