DOCUMENT:Q288121 27-FEB-2001 [iis] TITLE :BUG: Posting Acceptor Causes ASP Session to Be Lost PRODUCT :Internet Information Server PROD/VER:: OPER/SYS: KEYWORDS:kbASP kbInternet kbDSupport kbIIS kbGrpDSMSXML ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Internet Information Server ------------------------------------------------------------------------------- SYMPTOMS ======== When Microsoft Posting Acceptor is used to upload files to Internet Information Server (IIS), Session state is lost. CAUSE ===== Posting Acceptor is causing the Session cookie to be omitted when the cpshost.dll that is responsible for handling the file upload posts data to the repost URL. As a result, IIS sees the request as from a first-time caller and assigns it a new Session ID. RESOLUTION ========== Workarounds ----------- There are two possible workarounds for this problem: - Do not use session data or write all Session variables to Form variables on the page calling the Posting Acceptor and then rewrite them from the Repost page. In this event, the original session still uses memory on the server and eventually times out. This solution is not very robust or clean, and Microsoft does not recommended it. - A more robust workaround is to include a hidden form variable in the form that is used to upload the file that contains the user's ASP Session cookie. Then, in the onload event for the repost page, the cookie must be set again. While some browsers may be able to retrieve the correct Session cookie without this step, others never recover the session without it. Note that Session data is not available in the server-side code for the repost URL because the cookie does not yet exist at that time. If Session data is needed on the Repost page, the page can redirect to another page immediately upon loading. However, until this bug is fixed in Posting Acceptor, the server-side code on the Repost page is not able to access Session data. The following sample demonstrates the second workaround described previously. Keep in mind that Posting Acceptor needs to be installed on the server for the sample to work. Also, the proper permissions must be set on the directory referenced by the TargetURL form variable in the code in order for the upload to succeed. For more information, see the articles listed in the "References" section of this article. 1. Paste the following code into a new ASP page, and save the page as UploadFile.asp in a directory that is accessible from your Web site. This directory should allow write access for the IUSR (or IWAM, if run out-of-process) account on the Web server, both with NT file system and Microsoft Internet Information Server (IIS) permissions: <%@ Language=VBScript%> <% ' Get the repost path for the page, because you have to have the fully qualified path for the upload to succeed. Dim strRepostPath strRepostPath = "http://" + Request.ServerVariables("SERVER_NAME") + Request.ServerVariables("URL") strRepostPath = Left(strRepostPath, InStrRev(strRepostPath, "/")) %> Session ID: <%=Session.SessionID%>

File to upload:

2. Paste the following code into another new file, and save the file with the name RepostPage.asp in the same location as the previous file: <%@ Language=VBScript %> <% ' Get the repost path for the page, because you have to have the fully qualified path for the redirection to succeed. ' This is because this page erroneously believes it is in the /Scripts virtual root ' of the site that was called by the cpshost.dll file in that directory. Dim strRepostPath strRepostPath = "http://" + Request.ServerVariables("SERVER_NAME") + Request.ServerVariables("URL") strRepostPath = Left(strRepostPath, InStrRev(strRepostPath, "/")) %> Session ID should be (and was): <%=Request.Form("SessionID")%>
New (incorrect) session ID after post: <%=Session.SessionID%>
<% ' Abandon this false session so that the server releases it immediately. Session.Abandon %> 3. Paste the following code into a third new file, and save the file as SessionIsFixed.asp in the same location as the previous two files: <%@ Language=VBScript %> Fixed, original Session ID: <%=Session.SessionID%>
4. Finally, browse to the UploadFile.asp in your Internet browser, and upload a file. Note that you see the session lost and restored again. Remember that some browsers (Internet Explorer (IE), specifically) are capable of restoring the Session cookie simply by redirecting the URL. However, other browsers may not be able to do this, and lose the state of the Session unless the Session cookie is manually fixed. STATUS ====== Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. MORE INFORMATION ================ Steps to Reproduce Behavior --------------------------- To reproduce this problem, use the preceding sample code but remove the FixBrokenSession() function call from the onload event of the tag. The session is then lost. REFERENCES ========== For additional information about Posting Acceptor, click the article numbers below to view the articles in the Microsoft Knowledge Base: Q184352 HOWTO: Upload Files to the Internet Information Server Q217425 A Simple ASP Example Using Posting Acceptor Q230298 Posting Acceptor Release Notes Q241184 Posting Acceptor Returns Server Error 500 When Invalid File Name Is Used Additional query words: ====================================================================== Keywords : kbASP kbInternet kbDSupport kbIIS kbGrpDSMSXML Technology : kbiisSearch Version : : Issue type : kbbug Solution Type : kbpending ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.