I'm posting a resulting offline conversation here -
Reply From: Robert Chaplin [
[email protected]]
Ed,
I was afraid you'd ask that! I skirted the issue because it's not a
simple answer.
Basically, I'm serializing the view state to a temp file on the web
server that gets deleted when the session ends. We're using "sticky"
session state (InProc) on our web farm so that works well. If we ever
use StateServer or SQLServer session state I'll have to store the view
state data on a file server or as a session variable instead. I used
temp files for now because I wanted to avoid accumulating huge amounts
of view state in session.
BTW: If you have time could you post our exchange to the USENET thread
you started? I'm not hooked up with news right now (other than Google
searches). It might be helpful to others.
Thanks,
Bobby
-----Original Message-----
From: Henn, Ed [mailto:
[email protected]]
Sent: Tuesday, January 13, 2004 8:19 AM
To: Robert Chaplin
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication
Robert -
Clearly you were willing to go to much greater lengths than I was to
solve this issue. Glad to hear you got around it. Just out of
curiosity, how does your solution differ from setting sessionState to
"StateServer" or "SQLServer"? Where/how are you storing the viewstate
on the server? I have never dealt with that area of ASP.NET so bear
with me if I'm asking stupid questions. Thanks again
Ed
-----Original Message-----
From: Robert Chaplin [mailto:
[email protected]]
Sent: Monday, January 12, 2004 5:21 PM
To: Henn, Ed
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication
Ed,
We worked around the problem by overriding the page's
LoadPageStateFromPersistenceMedium() and
SavePageStateToPersistenceMedium() methods to save the view state
elsewhere (server-side). That way the large __VIEWSTATE form field is
not sent to the browser at all and we avoid the bug (whatever it is).
It consumes additional server resources but the nice thing is that it
saves a lot of bandwidth usage.
It would be nice to actually know what the real problem is, though,
instead of just addressing the symptom. Oh well...
I hope this helps.
Bobby
-----Original Message-----
From: Henn, Ed [mailto:
[email protected]]
Sent: Monday, January 12, 2004 2:09 PM
To: Robert Chaplin
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication
Sounds good, thanks for the additional info. I will let you know if we
find anything out also. Thanks
Ed
-----Original Message-----
From: Robert Chaplin [mailto:
[email protected]]
Sent: Monday, January 12, 2004 12:33 PM
To: Henn, Ed
Cc: Todd Thompson
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication
Thanks for the info. Perhaps we are not experiencing exactly the same
problem...
What we are seeing so far leads us to believe the problem is with the
IIS connection somewhere. The fact that Disabling keep-alive fixes it
supports this idea. And we also suspect that SSL (HTTPS) also avoids
the bug, but we can't verify that yet. We are not experiencing the bug
in one environment where SSL is the only difference we know of.
I'll let you know if we find out anything else.
-----Original Message-----
From: Henn, Ed [mailto:
[email protected]]
Sent: Monday, January 12, 2004 12:19 PM
To: Robert Chaplin
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication
Robert -
No, we didn't find a solution and your response is the first I've
received on this topic. I researched the issue a bit before posting,
and found a reference to a keep-alive solution on another post (not sure
if it was you or not). I tried it and it didn't work. But I appreciate
your suggestion. I was hoping to get some response from MS (hence "bug"
in the subject), but have received none so far. We'll see. Thanks
again for your help, and let me know if you run across anything new on
this issue.
Ed
-----Original Message-----
From: Robert Chaplin [mailto:
[email protected]]
Sent: Monday, January 12, 2004 11:02 AM
To: Henn, Ed
Cc: Todd Thompson
Subject: Re: Bug? Large Viewstate Breaks Forms Authentication
Did you ever find a solution to the large ViewState problem you found?
We're having a similar problem here. Curiously, we found that disabling
"HTTP Keep-alives" for the IIS web site in question prevents the problem
from happening. Maybe that's a clue to the cause. For performance, we
prefer to have HTTP Keep-alives enabled though.
Thanks in advance for any information.
---------------
In trying to solve a Forms Authentication problem I posted about earlier
("Forms Authentication - Bad Redirect on POST"), the problem now appears
to be due to having too much data stored in viewstate. I have found
several other references in this newsgroup to large viewstate causing
various problems, but not this specific issue. Can anyone confirm that
the following is a bug? I'd like to know if it can be fixed without the
obvious solution of turning off or limiting viewstate size.
The issue is that when a Forms Authentication session is timed out and
the user tries to POST on a page with approx. 50+ kb in viewstate, it
results in a 403.1 error (Execute Access Forbidden). Normally any GET
or POST after a Forms Auth session times out will result in being
redirected to the Login page.
When this error occurs, there is additional odd information in the web
logs. On the web log entry that would normally contain a GET for the
login page (redirected from the requested page), there is a corrupted
looking http verb (i.e. "b25kcztCZWFyIE...") in place of the GET, but
the rest of the line appears like normal.
I'm using VS.NET 2003, framework 1.1.
Can anyone at Microsoft confirm that this is a bug? Anyone else ever
have a similar problem and have a solution? Thanks in advance,
Ed Henn
Sacramento Superior Courts MIS
