.NET2 Web site form - can it be Broken?

[NickFitz]

I can fully understand what you mean for 5xxx errors but the ability to do this for errors is great as you get to keep the user on your site by displaying them actual content rather than any sort of error. I'd assume an error of any nature would have the bulk of users simply clicking back to Google. At least it gives you a last ditch attempt to say 'sorry, we couldnt do that, but do you want to buy one of THESE instead'.

You can do that without redirecting - in fact, Google and others strongly recommend using a custom 404 page, for example including a link to the home page, suggested alternatives, and a search box.

The point is that IIS, Apache or any other web server can serve a custom error page at the original URL. Using a redirect to take the client off to a completely different URL is just plain wrong, yet seems to be the only method allowed by ASP.NET.

Suppose, for example, that I type example.com/fo.htm into my browser's location bar. I get a nice friendly 404 page, and realise that it's a simple typo - I correct the location bar to read foo.html, and I'm done. That's not possible if the server has used a redirect, rather than serving the error in place. Instead I have to delete errorPage.html (or whatever) before I can correct the typo.

There is simply no good reason for redirecting errors to a different URL. RFC 2616 states that, in the case of client error (e.g. 404 Not Found) "the server SHOULD include an entity containing an explanation of the error situation" - it says nothing about serving an entity at a different location, and the fact that this is not explicitly forbidden doesn't make it acceptable.

It definitely makes no sense for a request that should return 404 Not Found to instead return 302 Found, which redirects to a page that returns 404 Not Found, when quite clearly the page redirected to has been found, and it was the page doing the redirection that was not found

Edit: yes, I've checked, and yes, that's what it does

[Durbs]

msdn states:

"The final task of Application_Error is to execute the Redirect() or Transfer(). From the discussion of configuring behavior above, you already know that which of these you choose is tied to how the Exception is stored, and that some combinations work while others don't. The features of the storage methods usually drive the decision.

But occasionally, features of Redirect() and Transfer() drive the decision. Redirect creates a new Context, Transfer does not. Redirect requires a round-trip to the browser, Transfer does not. As a result of this round-trip, Redirect rewrites the URL to reflect the location of the error page, Transfer does not.

If this seems to be an argument in favor of Transfer, it isn't. The built-in customErrors feature uses Redirect and not Transfer for a reason. The rationale of the ASP.NET development team is that Redirect accurately displays the URL of the custom error page, while Server.Transfer is intended for "switchboard"-style pages (as on content management sites) where the true URL is preferably hidden.

Therefore, while Context is one of the more convenient ways to move the Exception from Application_Error to the rich error page, its dependence on Server.Transfer() makes it less than perfect. While you may not be concerned that this approach breaks a tenet of the design philosophy of ASP.NET, be aware that it does.

The web.config <appSettings> tags to set the control-passing method and identify the custom error pages are:

<add key="customErrorBranchMethod" value="Redirect/Transfer" />
<add key="customErrorPage" value ="myErrorPage.aspx" />"

So, if you alter the customErrorBranchMethod to just "Transfer" would this have the desired affect? Not tried it as was unaware of this key prior to Googling the issue.

[NickFitz]

It sounds as if Transfer would have the desired effect of serving the CustomError content at the actual URL where the error occurred.

msdn states:
"...The rationale of the ASP.NET development team is that Redirect accurately displays the URL of the custom error page...

They don't give any reason why this should be considered a good thing - to my mind, it makes no sense at all to bother the client with internal details of how the server does its work

That's why I'm also vehemently opposed to URLs ending ".aspx" or ".php" and so forth - the implementation mechanism that serves the resource should not be part of the name of that resource. (Extensions like .html, however, denote the content-type of that specific representation of the resource,which is valid information to include in a URL.)

While you may not be concerned that this approach breaks a tenet of the design philosophy of ASP.NET, be aware that it does.

Interesting - this to me confirms that the "design philosophy of ASP.NET" is based on a complete misunderstanding of, or wilful decision to subvert, the HTTP standard.

(And don't get me started on the utter brokenness of ViewState )

[lightng]

(And don't get me started on the utter brokenness of ViewState )

So whats up with viewstate?

[NickFitz]

So whats up with viewstate?

I'll bite

ViewState wraps the entire page in one <form> element. However, HTML specifically allows for multiple form elements on a page.

So, using ViewState, you can't have (for example) a form for searching in the header of a page when that page contains a form for a separate purpose, without implementing a whole bunch of unnecessary logic on the server to determine which form you're supposed to be processing, as all form elements are part of the same overarching form.

For example:

<h1>HyperGlobalMegaCorp</h1>
<h2>Search</h2>
<form method="GET" action="/search">
    <label for="search">Search:</label>
    <input type="text" name="q" id="search">
    <input type="submit" value="Search">
</form>
<h2>Register</h2>
<form method="POST" action="/register">
    <label for="username">Username:</label>
    <input type="text" name="u" id="username">
    <label for="password">Password:</label>
    <input type="password" name="p" id="password">
    <input type="submit" value="Register">
</form>

is a typical use case for having more than one form on the same page.

However, that utterly simple implementation of the client-side user interface, and the equally simple separation of server-side concerns into distinct URLs seen in the action attributes of the two unrelated forms, is precluded by the use of ASP.NET's ViewState.

P.S. I'm pleased to see that a Google search for HyperGlobalMegaCorp currently shows my own site in fifth place

[DimPrawn]

You certainly know your stuff Mr Fitz.

It's a pity the original remit for ASP.NET was to "make the web look and feel like Windows forms" and not to "create the most elegant and natural web development framework possible".

Hence all the nastiness that lurks in ASP.NET that has to be worked around and hence the ermergence of the MS MVC Framework to avoid the mess in the first place.

Proper ASP.NET programmers use the raw .NET framework for HTTP handling and avoid the bloated controls, viewstate and limitations (ie single form) by using their own libraries of C# code.

Shame you have to work against ASP.NET to make secure, scalable, efficient, cross-browser, SEO friendly websites though.

[Ardesco]

I need to provide a simple "GuestBook" for a client BUT they are very concerned over abuse of the public facing web form (SQL injection etc)

I have scripted a demo guestbook http://www.stormtrack.co.uk/Pages/guestbook.aspx

I am using ASP validation controls, SQL2005 stored procedures as well as a final "post comment live" Maintenance page for the client (you don’t have access to this)

Have I got all bases covered - or is there anything else I need to consider??

Do you check the referring site? Its fairly easy to throw together a 5 second page that posts to your URL without using your form. This also means that any error checking you perform before the form is posted is redundant.

I've tested quite a few guestbooks where any page can post to it and the data is accepted without thought allowing SQL injection attacks, automated spamfests and all sorts of other unpleasantness.

[wxman]

Great, I can see that you have just posted a few test entries into the demo guestbook. I guess that I could script out the referring page to see where it is coming from.

Perhaps a better way would be to apply one of those Capthota [spelling] type control – the ones that generates a random string that has to be typed into a form before posting

Does anyone know of a FREE Capthota [spelling] script / control?

How do you spell Capthota anyway ???

Edit.....

CAPTCHA

like this one ?? http://www.protectwebform.com/

[voodooflux]

Does anyone know of a FREE Capthota [spelling] script / control?

How do you spell Capthota anyway ???

Edit.....

CAPTCHA

like this one ?? http://www.protectwebform.com/

Jeff Atwood posted a useful sample on his Coding Horror blog a while back - there are some good links to more resources in the comments to that blog post.

[lambrini_socialist]

If using SP's entirely and you dont have any dynamic SQL hiding anywhere then you should be good. Make sure you dont leave the customErrors mode="On" when finished developing it to give anyone a clue about any exceptions.

Also use the length= attribute for your textboxes to prevent people pasting huge amounts of text in to force DB errors.

the dynamic SQL thing is a myth and i do wish people wouldn't propagate it. the issue isn't SPs versus dynamic SQL, the issue is parameterisation (you need it).