Safari and coruupted Asp.Net ViewState following redirects.

Question

Safari and coruupted Asp.Net ViewState following redirects.

After downloading Safari for windows last night, I have tested it against our Asp.Net 2.0 web application framework and was dissapointed to see things not working.

After inspection with Fiddler etc. I have discovered that Safari does not like redirects and tends to get it's post back variables out of sync following a redirect. This is particularly noticable with the __VIEWSTATE hidden input field used by Asp.Net for tracking control state. Here I was seeing ViewState from a previous request being submitted in the request variables as the result of a post back.

I have seen one other thread regarding this issue in these discussion groups which came to the same conclusion.

By the way I have tried to move __VIEWSTATE to session state using microsoft's alternative SessionPageStatePersister inside a PageAdapter to no avail. In this scenario there is still a smaller stub __VIEWSTATE hidden input field used to co-ordinate the viewstate stored in the session state. Consequently the Safari bug still messes things up.

Our web framework works on IE 6/7, Firefox 1.5/2.0 and Opera 9.x has been passed through various xhtml validators to ensure the generated markup is legal. Therefore I believe the problem lies in Safari.

This has been a revelation to me as I haven't done enough testing against Safari and realize the problem is definitely something to do with server side redirects, something our web framework does a lot of as it uses meta-data driven business logic to navigate around the web site.

I gather the problem also effects the Mac version from the other old newsgroup threads.

Anybody had similar experiences.

Also anybody got an idea on how I can report an official bug to apple.

Thanks

HP/Compaq Laptop Nx8220 Windows XP Pro

Posted on Jun 13, 2007 6:48 AM

Reply

Answer 1

Jun 13, 2007 7:35 AM in response to Dave Stringer

Use the bug reporting button to the left of the address bar - i'd put this one under "Behaviour Wrong"

In terms of the __VIEWSTATE error, just out of curiosity, what happens if you spoof the user agent to be IE?

You'll need to activate the Debug menu (instructions here http://robrohan.com/2007/06/11/enable-debug-mode-on-safari-windows-error/) in order to select the User Agent

MacBook Pro 2.0 Mac OS X (10.4.9) 2GB RAM, 100GB 5400rpm

Reply

Answer 2

Jun 13, 2007 7:38 AM in response to Dave Stringer

Just done some more testing and realized Safari is only failing when Microsoft Ajax Extensions is enabled. Most of our web framework can work inside Microsoft Ajax UpdatePanels to minimize post back flicker.

So now I have narrowed the problem down to only when EnablePartialRendering="true" in the Ajax ScriptManager control. In this case it may be a java script bug that is not updating the post back variables correctly. In particular the __VIEWSTATE variable is continously updated on every post back when Ajax is enabled to ensure view state is in sync with application state.

Again no problems with other main browsers so will take a bit of debugging.

HP/Compaq Laptop Nx8220 Windows XP Pro

Reply

Answer 3

Jun 14, 2007 1:25 AM in response to Philip Jenkins

I've enabled the debug menu and changed the user agent to IE. The bug still occurs.

After inspection of microsoft's ajax script, the offending line is a window.location.href = ... assignment which is a client side redirect.
When redirecting using this approach the request variables collection in the browser looks like it is not being cleared. Hence the confusion with the __VIEWSTATE request variable. The other browsers IE, Firefox and Opera do not exhibit this behavior.

It looks like its only window.location.href redirects that are failing. The more traditional 302 redirects that Asp.Net used to render before the arrival of ajax are OK.

Reply

Answer 4

Jun 14, 2007 2:47 AM in response to Dave Stringer

This does seem like a genuine Safari/WebKit problem - there's some more ViewState discussion here http://west-wind.com/WebLog/posts/2588.aspx (no solutions though unfortunately)

Reply

Answer 5

Jun 14, 2007 3:55 AM in response to Philip Jenkins

Just achieved a workaround for the present that turns of the partial rendering capability of Ajax if a Safari browser is detected. At least the web apllications still work event if there UI is more sluggish.

Refering to your referenced post http://west-wind.com/WebLog/posts/2588.aspx. I see the date of the posting is late 2005 and I am not seeing bugs with conventional 302 redirects. It looks like older versions of Safari may have been buggy with 302 redirects.

I wonder if they've partially fixed the bug so that 302 redirects are now good, but there is still a bug with client scripted redirects using window.location.href.
Just a theory.

Reply