locked
Transfer-Encoding header being removed from response RRS feed

  • Question

  • User-1227792765 posted

    I am having an issue with ARR removing the "Transfer-Encoding" header and was in hopes someone might have some insight on it.  Currently we are using ARR to sit in front of several server farms.  We are using ARR set with routing rules of SSL offloading to pass the request internally to the various web servers and we are also using server affinity.  This has all be working fine and we are currently running on IIS 10 with ARR 2.5 (fully updated).

    My problem is, I have a WebAPI application running inside of the server farm.  This application has an endpoint which returns data, the size of which is not known by the application at runtime.  The data is streamed using PushStreamContent and the Transfer-Encoding header is set to “chunked”.  When the response is returned to the client, the transfer-encoding header has been removed.

    I have confirmed the web farm server is returning the header by connecting directly to the server, but ARR is removing it for some reason.  Even if I set a URL rewrite rule in ARR to add the header back in, it seems to still get stripped out.

    I have also confirmed the “enableChunkedEncoding” is set to “true” on my ARR server, but for some reason I still cannot get the header to present itself.

    Does anyone have any ideas here?  The connection is not being lost between ARR and the web server because I have several clients which are easily able to get the data, but I have a client whose web client thinks since content-length isn’t set and there is no Transfer-Encoding, the connection should be dropped.  It is very odd.

    Tuesday, December 22, 2020 6:29 PM

All replies

  • User1065476709 posted

    Hi ggoodnight,

    ggoodnight

    I have also confirmed the “enableChunkedEncoding” is set to “true” on my ARR server, but for some reason I still cannot get the header to present itself.

    Is the enableChunkedEncoding value you set the AspEnableChunkedEncoding value?

    To enable chunked transfer encoding, set the value for AspEnableChunkedEncoding to True for the site, the server, or the virtual directory that you want to enable chunked transfer encoding for:

    • Open a command prompt.
    • Change to the Inetpub\Adminscripts folder.
    • Run the following: cscript adsutil.vbs set /W3SVC/AspEnableChunkedEncoding "TRUE"

    Best regards,

    Sam

    Wednesday, December 23, 2020 9:47 AM
  • User-1227792765 posted

    Hi Sam,

    Yes that is the same setting, or at least I think it is.  If you look in the configuration editor for the server, the setting is listed under "system.webServer/asp".  I have seen the script recommendation, but I can't seem to locate that script to give it a try.

    Thanks,

    Grant

    Wednesday, December 23, 2020 1:58 PM
  • User-2064283741 posted

    So some/most clients from are ok and this performs as expected but for 1 client it does not?

    I suggest it might be an issue with that 1 client. There can be a lot of things in the way of getting from the client to your ARR - proxies, firewalls! network kit, and the client browser itself, etc

    Wednesday, December 23, 2020 6:13 PM
  • User-1227792765 posted

    Admittedly my statement was somewhat misleading about the client issue. 

     

    The client is having an issue with the fact the “Transfer-Encoding” header is being removed, while others are not.  The fact is the header IS being removed from EACH response, not just this particular client.  It is also a fact that the header is present when the response is transmitted back to ARR from the underlying web farm server; ARR is removing the header before transmitting the response.  I have further proven this by connecting directly to the ARR server, bypassing firewalls etc.  The fact I have a single client having an issue with the header missing is likely moot and I should have probably omitted that detail.

     

    As I also stated, even trying to make every response have the Transfer-Encoding header present using URL rewrite still doesn’t work, ARR removes it no matter the circumstance.

    Wednesday, December 23, 2020 6:48 PM
  • User-2064283741 posted

    Ok that is clearer now. 

    What is failed request tracing saying? 

    Run it on both the webserver and the ARR server and see what removed it. And at what stage in the process. 

    Wednesday, December 23, 2020 8:22 PM
  • User-1227792765 posted

    Thank you, I'll check this out when I get back into the office after the holidays.  My question though, is would failed request tracing even pick anything up, given the request and response are not failing?  I am getting my data back when I run the endpoint, just minus the Transfer-Encoding header I should be getting.

    Wednesday, December 23, 2020 8:44 PM
  • User-2064283741 posted

    Failed request tracing is not just about failed requests. It is any requests and breaks it down into the hundreds of processes that IIS does to each part. 

    Thursday, December 24, 2020 5:06 AM
  • User-1227792765 posted

    Yeah I forgot you could set the status code range.

    Ok, well now I am even more confused.  I was able to take a look and the web server is clearly setting the header, but ARR isn't returning it.  Here are the General_Response_Headers from both servers.

    ARR -

    <Data Name="Headers">

    Cache-Control: no-cache
    Pragma: no-cache
    Content-Type: application/json
    Expires: -1
    Server: Server
    Access-Control-Allow-Origin: *
    X-XSS-Protection: 1; mode=block
    X-Content-Type-Options: nosniff
    X-Permitted-Cross-Domain-Policies: none
    X-Frame-Options: sameorigin
    Strict-Transport-Security: max-age=31536000; includeSubDomains
    Referrer-Policy: strict-origin-when-cross-origin
    </Data>

    Web Server -

    <Data Name="Headers">Cache-Control: no-cache
    Pragma: no-cache
    Transfer-Encoding: chunked
    Content-Type: application/json
    Expires: -1
    Server: Microsoft-IIS/10.0
    Access-Control-Allow-Origin: *
    X-XSS-Protection: 1; mode=block
    X-Content-Type-Options: nosniff
    X-Permitted-Cross-Domain-Policies: none
    </Data>

    I don't see anywhere in the entire trace where ARR references that header at all, yet it would appear it should be receiving it.  I would also note there is no hardware in between these servers, they are on the same subnet and communicating directly with each other.

    I also want to note, this was a direct connection to ARR, not going though any firewall to access the site.

    Thursday, December 24, 2020 2:57 PM
  • User1065476709 posted

    Hi ggoodnight,

    Please check your HTTP version, as far as i know chunked transfer encoding is used only by browsers that support and have HTTP 1.1 enabled.

    Best regards,

    Sam

    Friday, December 25, 2020 8:12 AM
  • User-1227792765 posted

    Yes it is HTTP 1.1 for the requests.  

    Friday, December 25, 2020 9:25 AM
  • User1065476709 posted

    Hi ggoodnight,

    Generally, arr will not remove the Transfer-Encoding header unless you have some special settings, for example, you use the url rewrite rule in arr to remove it, so please check if there are any special settings in your arr.

    Best regards,

    Sam

    Monday, December 28, 2020 7:49 AM