Question

Consider the following case:

• A web server is running a .NET app with <sessionState cookieless="AutoDetect" />.
• A client is POSTing data to it using a simple HttpWebRequest (no cookies).

This seemingly simple case causes major failure.

Since .NET can’t determine if the requesting agent (HttpWebRequest) supports cookies, it responds to the POST request with a 302 Found redirect to the same location with:

• a cookie named AspxAutoDetectCookie in the response
• a query parameter named AspxAutoDetectCookie in the forwarded location

The requesting agent is then supposed to request the new location, which HttpWebRequest does. When .NET sees AspxAutoDetectCookie in the query string, it knows this is a re-request, and it can determine if cookies are supported by seeing if a cookie named AspxAutoDetectCookie is in the request headers.

The problem is that most requesting agents (web browsers, HttpWebRequest) treat a 302 Found as if it is a 303 See Other and make the re-request a GET, regardless of the original HTTP method! Any data sent in the initial POST request is not forwarded.

The correct response should be a 307 Temporary Redirect, which does not change the request method. (A POST request to location X redirects to a POST request to location Y.)

Is there any way to change this behaviour in .NET so POST requests are not destroyed?

Information on 3xx redirection

Answer 1

The only solution I can see to this is to append AspxAutoDetectCookie=1 to all POST requests.

This way, ASP.NET will never redirect the request and we can dodge the 302 vs 307 question altogether. If cookies are embedded in the request, ASP.NET will detect that cookies are supported, and if no cookies are embedded, it will assume they aren’t.