HTTP response split attacks, HttpWebRequest and the NET Framework 1.1 SP1

The .NET Framework 1.1 SP1 shipped recently and was pushed to Windows Update so you probably were already offered to download it. There is a package for Windows XP and or Windows Server 2003.

This release contains several fixes but also attempts to enhance security. This is the case of System.Web.HttpWebRequest. It now detects if an HTTP reponse split attack might be in progress and raises “The server committed an HTTP protocol violation” error.

For instance, look at this example of HTTP headers returned by some server:

HTTP/1.1 200 OK
Content-Length: 4171
Date: Fri, 03 Sep 2004 18:02:23 GMT
Content-Type: text/xml
Last-Modified: Fri, 03 Sep 2004 17:08:42 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content Length: 51

When presented with this response, the SP1 version of HttpWebRequest will fail because you can’t have a space in a header name. It should really be Content-Length. As you can see, the client application will raise an exception but the server is really at fault here and should be fixed. The client only protect itself by refusing a non-conformant, potentially dangerous response.

This change has already been noticed, mostly by user of .NET based RSS aggregators and they figured out that there is a way to disable the security improvements by altering the appropriate .config file.

        <httpWebRequest useUnsafeHeaderParsing=”true” />

This setting is only recognized by .NET 1.1 SP1. If you only have .NET 1.1, your application will fail if it encounters this setting. It might make installers slightly more complex.

Now, let me get on my soap box for a second: I know it is tempting to revert back to the unsafe header parsing to “fix” this but resist the temptation. If you find a site that exposes this behavior, contact them and ask them to fix it.

Comments (17)

  1. Aleks says:


    i think that my web site have this security problem on two pages (rss and a page that display a picture

    One use ContentType="text/xml" and the other ContentType="image/gif"

    I will try to night to change the web.config but how can i fix it in other way (the secure way ?)

    Thank you

  2. Gilles says:

    Aleks: By reading your post, it is not immediately obvious that your site has this problem. There does not seem to be any spaces in ContentType which would indicate that this header is not the issue, if there is any issue. Are you 100% sure that there is an issue with the headers?

    Headers can come from two location: first the web application running (i.e. showimage.aspx) and the HTTP request processor (IIS and/or ASP.NET).

    IIS does not return "wrong" headers by default. ASP.NET, to the best of my knowledge does not either but does not prevent a web application to return malformed header names. If you suspect such a problem, I would start by looking at the application. Be sure to look at all HTTP handlers that might be modifying the stream after the page has been rendered.

    To fix it, you would find the offending code (the one that returns the wring header), change it to be a "good" header and rebuild the code.

  3. Aleks says:

    Thx Gilles for your response.

    I tried to change my web.config and you’re right this is not my problem.

    I’ve just make a small winapp to see informations such as headers that my page return and i was very surprised :

    When i look to the headers return by my local testing server it is all right BUT when i try to the main server ( the ContentType header is missing.

    The two servers run the same code and have the same webpages.

    Is it a security fix ?

    Have an idea ?

    Thx for your help

  4. Ramkumar says:

    Hi Gilles

    We are having issue with biztalk not able to send over 50 kb of xml over http protocol thru biztalk.I couldnt find any article abt this issue.I would really appreciate if u can throw light on this subject



  5. Gilles says:

    Ramkumar: Biztalk 2004 uses POST to send data so it should be able to send more than 50Kb. This is most likely a configuration issue on the Web Application and/or BizTalk. You do not explain what happens exactly when you try to send more than 5oKb: any error, special behavior … so it is impossible for me to figure out what is wrong in your specific case without looking at your system(s).

    Take a look at the web server logs and see if there is anything wrong there. Look for connections close, unusal status … Take a look at the BizTalk machine’s event log and see if there is anything wrong there as well.

    A few things to check:

    1) any proxy server in between that would limit the amount of a POST request?

    2) you are sending the data in the body, right?

    3) use a network monitoring tool like netmon or tcpdump (or ethereal) to capture the whole faulty HTTP session. You will be able to figure out who (if any) closes the connection first, what is the status of the close, how much data went in… It is important to figure out if BizTalk closes the connection first of if the web application is closing first even though BizTalk has more data to send,

    4) are you sure you are not timing out while transmitting?

    5) write a small web application that just saves the content to a file and point BizTalk to it so you can control the server yourself.

    6) are you sure you are actually sending the right data? Maybe your send pipeline (if any) does not produce the data you expect (i.e. it produces less data than expected for instance). The HTTP send adapter will send only what it receives.

    There are of course so much more things you would normally check but this is going to get you started.

  6. Ramkumar says:


    Thank you so much for the information.We have tried all the methods what you have mentioned steps.It seems BizTalk sends chunk of data over 48 kb and they have hotfix from microsoft to install the fix;%5bLN%5d;839663#appliesto

    Though after installing the hot fix we are in the same state getting bad response from the http server 400.If you can throw more light on this area we would really appreciate your help



  7. Ramkumar says:


    W finally figured it out after making the changes in registry key mentioned in KB 839633



  8. Gilles says:

    Ramkumar: I m glad you got it to work. So this was the chunk encoding that ws causing issues.

  9. Apparently there’s a minor disconnect between these three items and RSS2 feeds. You’ll notice that the last time I recieved a feed from nf0’s Life was on the 23rd of September. The last update from scriptygoddess was on the 24th….

  10. The server committed an HTTP protocol violation

  11. Anonymous says:

    journeying geek &raquo; Your WordPress feeds are broken!