Interestingly, it worked great on IE and Safari, but failed on Chrome and Firefox. What was even stranger was that everything worked properly when debugging in Visual Studio, but the failure occurred when the site was deployed to IIS.
So the failure occurred only when running Firefox or Chrome against IIS. The same website with IE and Safari worked great, and the same website on Cassini worked great in any web browser.
Hmm...
I ended up using WinDiff to compare the HTML output differences between what was served up from Cassini (Visual Studio during debugging) and IIS. There was one line that was different:
On Cassini:
<form name="aspnetForm" method="post" action="/default.aspx?" id="aspnetForm">
On IIS
<form name="aspnetForm" method="post" action="/" id="aspnetForm">
That was the clue that I needed. Apparently Cassini was directing users to /default.aspx, whereas IIS was directing users to / (which loaded default.aspx as the default page). Sure enough, if I went on the site on IIS and manually typed in /default.aspx in the address bar and then clicked a button on the page, the POST worked properly.
Requiring users to type that in manually is not a great solution, so I added a default.htm page that redirects to default.aspx, solving the problem. Default.aspx is now explicitly shown in the address bar, and the problem is no more.
3 comments:
I have a similar issue. In my situation, the page works fine on IE and Chrome, not on Safari. If I debug using the visual studio development server, the button postback works fine on Safari; when I debug using the IIS, which is the real site, the post back doesn't work on the Safari. It will post back, but the postback status is still false, instead of true, therefore, nothing happens, except a refresh of the page. I tried your method to compare the html codes; and I found they are exactly the same. Any idea why postback is lost on the real site for Safari; but preserved in the development server? Thanks a bunch
For Safari, I would recommend trying to see if a POST is actually being sent to the server using a tool such as fiddler. This will also help you see if something else happens after the initial POST (such as a redirect to a page that is then retrieved with GET)
Tim,
Thanks very much. This recommandation leads me to find the solution. It seems Safari responds well only to the full domain name. I used localhost before and it was failing; but I changed to the full domain name, it works fine now.
Post a Comment