Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is it possible to define a particular folder to be cookieless in IIS7, instead of just the root?

share|improve this question
    
I think you are worrying about YSlow suggestion "Use cookie-free domains". Explanation can be found here: developer.yahoo.com/performance/rules.html#cookie_free –  Veton Oct 10 '11 at 9:40
    
That's exactly what I'm worrying about. And traditionally, I've been creating a seperate website on the IIS server which has a web.config entry to say 'no session state and no cookies'. I was hoping to AVOID creating this second website (with the duplicated static content) and just be smart enough to use the main site but have certain folders say 'no cookies in the response, please'. –  Pure.Krome Oct 10 '11 at 23:27

2 Answers 2

up vote 6 down vote accepted

This is more of an ASP.NET question than an IIS question.

A regular folder cannot have session state "defined" (i.e. InProc, SessionState, SQLServer, cookieless). However, if you mark a folder as an application then you can disable session state for that application. Additionally, you can disable session state per file if you want.

However, the element in web.config can be set at any level and it will completely disable session state for you. You can set it in web.config in the folders that you don't want it like so:

<system.web>
   <pages enableSessionState="false" />
</system.web>

Or you can set it in the root for a number of folders, like so:

<location path="images">
    <system.web>
        <pages enableSessionState="false" />
    </system.web>
</location>
<location path="css">
    <system.web>
        <pages enableSessionState="false" />
    </system.web>
</location>
share|improve this answer
    
Damn. that really sucks then :( Damn damn danm. The idea here was to make the /Images /Css and /Javascript folders all COOKIELESS, while the rest of the app is InProc. damn. –  Pure.Krome Oct 25 '09 at 0:21
2  
Actually, you're ok. You're good. Session state (cookies) are only used with managed code file types so session state isn't loaded for any images, css and javascript files anyway. –  Scott Forsyth - MVP Oct 25 '09 at 4:04
    
Correct. It might not be loaded but it is still PASSED down the wire, to the IIS server .. which is a waste of bandwidth for heavy load sites. That's my issue :) –  Pure.Krome Oct 26 '09 at 23:50
1  
The tiny cookie saved for your domain will be passed with all page requests in the HTTP header, but that's all that is passed back and forth. That won't amount to anything significant, even for heavy load sites, and it won't even be used by ASP.NET so there isn't any processing overhead. The actual session state isn't loaded from memory for non-managed code. Viewstate is a different story. That can consume a lot of bandwidth. It's only included for managed code pages too though. Check out port80software.com. They have some great tools for customizing client-side caching and performance. –  Scott Forsyth - MVP Oct 27 '09 at 2:13
1  
I updated my reply. Turns out that <pages enableSessionState="false" /> can be set at any level. It can't change the type to cookieless but it can disable session state completely. –  Scott Forsyth - MVP Oct 27 '09 at 2:18

Create another domain for cookieless elements such as images, js and css, then make them cookieless. The cookie setting works per domain (or subdomain) than per folder.

share|improve this answer
1  
Correct, but that was what I was trying to avoid. Having another hostname / cnd .. sure .. but physically creating another website in IIS just for cookieless .. is what I've been doing before but was hoping I can avoid. –  Pure.Krome Oct 10 '11 at 23:25
    
yes this works but i also want to avoid this –  MonsterMMORPG Jul 23 '13 at 23:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.