Avoiding "connection: close" when returning a 304 (Not Modified) status code in ASP.NET (Part 2)

Posted on September 11th, 2007.

In part 1 I discussed how to return a HTTP 304 status code when you don’t want to send clients an entire response if the client already has an updated version of the page in their cache.

How can you verify this is actually working as you expect? You can an HTTP monitoring tool to see the requests your browser send and the responses the web server sends back. My favorite tool for this is Fiddler

Here’s a screen capture  of fiddler (click the link to see a larger image):

Fiddler

Notice that the first request we get is a regular HTTP 200 response with the actual data (5 bytes in our case as seen in the body column). The second and third requests return a 304 response as expected.

If you look at the request headers you’ll see the expected If-Modified-Since (upper right pane) :

Fiddler2 
The Fiddler Timeline add-in provides a graphical layout of the requests, their timing, cache status and connection status. If you’ll go back to the first image you’ll notice that the second and third requests have a floppy icon near them which means these requests were served from the local cache instead of the server. You might also notice a red circle near that floppy.. That’s what this post is all about.

The red circle means the connection will be ended by the server after the response is over. This is also indicated by a “Connection: Close” header that was added to the response (which you can see in image 2 in the lower right pane). Why was the connection closed? The simple answer is because there’s no content-length header in the response. Yeah, so? So, if there’s not content-length header, then the client has no way of knowing when the response is finished and will just keep waiting for more data from the server. Ahh.., but why wasn’t the content-length header added? Well, I have no idea why. What I can tell you is that if your client is going to send another request to your server right after this one, it won’t be able to reuse that connection and will have to open a new one which, in some cases, is just a waste of time. So how do you avoid that? Simple:

context.Response.AddHeader("content-length", "0");

 
Since we’re not sending any content (That’s what a 304 response is all about), we simply add that header. ASP.NET will now realize that the response is actually empty and there’s no reason to close the connection and will not add that header.

Make a Comment

2 Responses to “Avoiding "connection: close" when returning a 304 (Not Modified) status code in ASP.NET (Part 2)”

RSS Feed for Eyal’s Posts Comments RSS Feed

Excellent! Exactly what I was looking for. Setting content-length to 0 did the trick. Thanks!

Koen
July 22nd, 2008

Hello Eyal,
This is regarding your sample code post on codeproject..
http://www.codeproject.com/KB/cs/IFilter.aspx?msg=3128621

I’m getting following error when I close your tester executable after successfully reading selected PDF file.

—————————————————————————————
.NET-BroadcastEventWindow.2.0.0.0.378734a.0: IFilterTester.exe – Application Error
—————————————————————————————
The instruction at “0x0700609c” referenced memory at “0x00000014”. The memory could not be “read”.

Could you please look into this and help me out.

Thanks in advance.

Regards,
Ganesh.

Ganesh
January 8th, 2010

Where's The Comment Form?

eXTReMe Tracker