Postback quit working

C

Craig

I recently encountered an odd problem that has me rather baffled.

I have a number of web applications on a staging server that have suddenly
quit posting back when the user clicks a submit button. The exact same code
works correctly on the production servers.

In my attempts to trace this problem, I've simplified it to this. Any time
that I add a required field validator control (and perhaps other validation
controls - I've tested only the required field validator) to a form, the
form will no longer submit when the user clicks the submit button. I
created a very simple web form to test my theory. The form contains one
lable, one textbox, one button, and one required field validator whose
control to validate property I set to the textbox. The code behind the
button simply sets the label's text property to the textbox's text property
and clears the textbox only if the page successfully validates.

If I leave the textbox empty and click the button, the required field
validator does its job; however, if I enter text into the textbox and click
the submit button, no events fire - not even the page_load event. If I
remove the required field validator, everything works fine. The textbox text
appears in the label, and the textbox clears.

I've tried replacing the staging server's aspnet_client folder with that
from one of the production servers, but doing so made no difference.
Additionallyu, the NTFS permissions on the staging server match those on the
production servers. I'm stumped, and I have no idea what else to check.

I would sincerely apprectiate any assistance someone could offer.
 
F

Frank Mamone

Many postback problems have been attributed to .NET 1.1 SP1.

Have you upgraded lately? That could be the problem. Apparently, it's a
problem with the js file the framework uses to create the postback
functionality. Since it has the same name , the old one is cached on the
browser or elsewhere and the new one doesn't get downloaded. That of course
causes problems.

Hope this helps.

Frank Mamone
 
C

Craig

Well, I haven't upgraded since Friday, and I'm fairly certain that the forms
worked correctly on Friday. Further, I upgraded to 1.1 sp1 prior to
developing the forms in question. However, subsequent to your post, I
cleared my cache, and I still encounter the same failure. I've also since
discovered another oddity. The forms work correctly in just about every
other available browser *except* IE.

Any other ideas?

Craig
 
C

Christie Sorenson

Not a suggestion, but another comment. I'm having the
exact same problem. There seem to be a number of us
across a few boards with this problem that has arisen
since Friday. I have seen on another board that the
faulty file is webuivalidation.js. I do not know if the
wrong file is being served or if there is anyway to fix
it, but I would love to know!
Thanks,
Christie
 
K

Kikoz

There is one solution that would fix this and many other related problems:
STOP USING that freaking validator. Use System.Exception instead. Much
easier and cleaner. If you need an example ask here and I'll post one for
you.
 
C

Craig

Hi Christie:

The first of the urls in your response did the trick for me.

Thanks!

Craig
 
C

Craig

Am I wrong in thinking that System.Exception is server side? I use plenty
of server side error trapping, but why would I want to scrap client side
validation in favor of server side validation? Don't the increased round
trips to the server kill performance?

Please do enlighten me.

Cheers!
Craig
 
K

Kikoz

Just to enlighten you :)

You are totally correct on one thing: System.Exception is server side. If
your code is so bad that you're concerned about "killing performance"...
Well, than you have a much bigger problem than validator thing. If not than
I can tell you that for years of developing web-based applications I haven't
seen ANY single complain from users that because I use server-side
validation they gonna stop using the app. And my servers don't complain
either (unless you get 30,000 concurrent users every day... But you don't,
don't you?). Those "increased round trips" will save your application and
sometimes your ass by making sure that only correct data has been received
(for example, if you store form values in db and your page faces serious Sql
Injection, XSS or One-Click attack). And even if you parameterize your data
layer (if any) then you still gonna get weird data entries sooner or later
simply because any user can disable client scripting in any browser at any
time. For plenty of them it's like a sport. There are thousands of kids out
there who have a great fun just by "light-hacking" this kind of situations.
I bet you use Form authentication to authenticate your users, too. Right? :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,057
Latest member
KetoBeezACVGummies

Latest Threads

Top