locked
HttpPlatformHandler is returning Keep-Alive header to IIS RRS feed

  • Question

  • User-111908839 posted

    We are hosting Java spring boot application with tomcat 9.0.31 behind IIS 10 and HttpPlatformHandler 1.2

    The problem is that httpPlatformHandler is returning the Keep-Alive header as is from tomcat to the IIS and after that IIS returns it to the client through http2 connection.

    According to the spec of http2, the Keep-Alive header is prohibited (https://tools.ietf.org/html/rfc7540#section-8.1.2.2)

    According to this (https://tools.ietf.org/html/rfc7230#section-6) : 

    A proxy or gateway MUST parse a received Connection header field before

    a message is forwarded and, for each connection-option in this field,

    remove any header field(s) from the message with the same name as the

    connection-option, and then remove the Connection header field itself

    (or replace it with the intermediary's own connection options for the

    forwarded message).

    I looked at here https://github.com/dotnet/aspnetcore/blob/8e4dadc0dd69b462bd0e562863f8414aceb1dca1/src/Servers/IIS/AspNetCoreModuleV2/OutOfProcessRequestHandler/forwardinghandler.cpp#L2218 

    and if i am not wrong the AspNetCoreModuleV2 is removing the connection header but does not remove the other headers related to the "connection" header - keep alive

    As far as i know the AspNetCoreModuleV2  is based on HttpPlatformHandler so i assume the code is almost the same.

    Is there a solution or workaround ?

    Atanas

    Friday, June 5, 2020 12:33 PM

All replies

  • User-1202101404 posted

    While I don't have enough experience with that header or module to offer a solution specific to them, I will offer this: if you implement the IIS URL Rewrite feature, you should be able to use THAT to remove the header from the response.

    I am assuming that's what you mean: you don't want the client (browser or whatever) to see the keep-alive header, right? Again, someone else may have a better solution that is specific to configuring either that module, or IIS, or Tomcat, to "stop" sending that header.

    But while the name of the tool is "url rewrite" and that is the main job people use it for (manipulating incoming REQUESTs), it CAN in fact be used to manipulate the outgoing RESPONSE before it leaves IIS.  And that can including modifying or even removing undesired headers.

    There are various examples of this, Folks have used it to remove the X-POWERED-BY header that IIS generates, for instance. Sometimes a feature in IIS that SHOULD remove such a header somehow starts showing it again. A rewrite rule is a way to forcefully remove it. One example of that is here, or there's another about using it to remove a different header here

    Again, I realize you may feel you should not need to resort to this, and maybe there is a better solution. I offer it until that may be presented by someone else. (Note that you DO have to install that url rewrite tool. It is not enabled in IIS by default, nor even offered as an available option for IIS out of the box. It must be installed, but it is from Microsoft.)

    Let us know if that may help or if you might object to even trying it.

    Friday, June 5, 2020 4:59 PM
  • User-111908839 posted
    Yes we are using exactly the url rewrite module right now as a workaround, but i was thinking that may be there is another solution or fix (if this behaviour is not intended by design) in the httpplatformhandler.
    Friday, June 5, 2020 5:48 PM